Like most rule changes, this petition has drawn fierce opinions both for and against it. The problem is that most of the arguments against it are not technical in nature, but against the idea that wide modes will be allowed on the digital sub- bands and thus cause interference.
Ironically, this petition will impose a bandwidth restriction on the HF bands for the first time. As the rules stand now, you could have a 6 KHz wide digital signal as long as the symbol rate didn't exceed 300 baud. The new rules will allow any baud, but the signal can only be 2.8 KHz wide.
The thing with both of these signal properties is that they are effectively self-limiting. Higher baud rates are subject to fading and multi-path distortion so they are effectively limited on HF, especially the lower bands. Bandwidth is limited by the standard SSB radio bandwidth of about 2.8 KHz, with most being closer to 2.4 KHz. Granted some SRD radios could have wider front ends, but this is far more the exception than the rule.
What opponents miss by their disdain of Pactor 4 (the most prominent mode that is driving this petition) is that increasing the baud rate can actually lead to a variety of faster modes with less bandwidth. Most multi-tone modes can use fewer tones at a faster symbol rate and move as much data than they could with more tones at a slower baud rate. This would allow a reasonably fast data stream in a 1 KHz bandwidth that would deliver a higher power density and eliminate the need for a 2 KHz wide mode running at a lower baud rate. This is effectively the difference between Pactor 3 and 4 in general.
Of course some argue that we amateurs don't need to move data that quickly on HF. Pactor 2 and Clover II are plenty fast with their reasonable 500 Hz wide signal. To this I have to point out that amateurs are trustees of a large swath of lucrative radio spectrum. If we cannot justify our continued use of these frequency bands, then the government is liable to sell it to the highest bidder in the name of the common good. Since radio amateurs seem to be falling way behind in the development of the radio arts due to a variety of factors, the ARRL has taken the tact with the government that we are a pool of trained communicators. We can provide government and non-government agencies with communications capability at little cost in times of need. Part of this scheme, and one of the most crucial, is supplying long-range email capability on HF. This requires more than the 800 bps than P2 or Clover can provide. Since a minor rule change will provide up to 5000 bps via Pactor IV and other similar modes, they are taking the steps necessary to make it happen.
73
Jeremy
Saturday, December 21, 2013
Wednesday, May 15, 2013
Playing with APRS
APRS has seemed to be the most wide spread use of VHF packet mode for many years now. I have been on the fringe of this system by having a mobile tracker in my car off and on for the last 10 years. N1ZZZ-9 has had a nice run across the US several times, and in the areas close to my various home QTH over the years. These days with a new car, and a XYL who isn't too keen on having it's finish marred by an external antenna, the Kenwood TH-7 has degraded from a mag-mount antenna to a rubber duckie. Of course the rubber duckie antenna isn't very good at getting the signal out.
For the last two years or so, I have also had a portable station, N1ZZZ-7, on the air in the form of a Yaesu VX-8. Again, when walking around with an H-t on your belt and a rubber duckie, your signal isn't going to get too far, but it sometimes manages to get my signal out to digipeaters.
I have been fortunate here in the Wilkes-Barre, PA area. While standard packet is almost non-existent, the APRS system is very strong, especially along the I-81 corridor. There are several Digipeaters as well as a capable I-Gate to send the signals into the Internet for all to see.
What I have never done in all of these years, has been using APRS in it's most interesting incarnation, and that is with a fixed station, with a "real" TNC, and a mapping display to show where all of these beacons are.
This past week, I finally found a program that suited my needs and worked with the equipment I already had. The program was APRSIS32. The program was an easy download and installed quickly. The program connected to the APRS servers via the WiFi port in my computer and immediately started to download maps and place beacons on the screen through the IGates. The next step was getting my GPS to talk to the program.
I have a Garmin GLO GNSS receiver that connects via a Bluetooth link. This little receiver uses both the American military's GPS system and the Russian governments GLONASS constellation. Getting this device to talk to the APRSIC32 program proved to be a very easy. I turned on the GLO and enabled the GPS via Bluetooth in the program and it immediately found a fix. Not only did the program display my position both in Lat/Long, but also gave me a grid locator. The station's speed (0 at this time) is also prominently displayed on the screen. Most interesting to me was that the program also displayed the number and status of satellites in both the GLONASS and GPS systems. Even with my GLO on my desk near the window, I am getting better than 20 satellites in the list. These satellites' geographic position are also displayed on the screen as they float on by.
Getting my Kantronics 9612 TNC hooked up proved to me more difficult. The TNC needs to be in KISS mode, but I also use it for normal packet, so I can't get the 9612 "stuck" in that mode. I needed the program to start the 9612 in KISS mode, and then return it to Terminal mode when the program exited. Kantronics TNC's are a bit fussy in my experience and this proved to be no different. I knew that the computer was able to talk to the modem because I was able to use the AirMail dumb terminal was able to get me command prompts, but the APRSIC32 was not able to find it properly. While the program claimed that the radio port was active, it would not key the TNC or get any packets from the radio.
The problem is in the XML script located in the local folder where APRSIC32 is situated. This is a far cry from the plug-and-play software that is the norm today. To fix this problem, I had to do some internet research. The program's wiki talks about the lines for a Kantronics KPC, but not the 9612 specifically. In the interest of sharing the data, I will post the script from my XML file here so that anyone who needs it can cut and paste and get it working.
<!--RFPort[0]-->
<RFPort Name="KAM">
<Protocol>KISS</Protocol>
<Device>COM4:9600,N,8,1</Device>
<RfBaud>1200</RfBaud>
<OpenCmd>^M~</OpenCmd>
<OpenCmd>^M~</OpenCmd>
<OpenCmd>XFLOW ON!!0</OpenCmd>
<OpenCmd>FULLDUP OFF</OpenCmd>
<OpenCmd>INT KISS!!0</OpenCmd>
<OpenCmd>RESET!!0</OpenCmd>
<CloseCmd>^192^255^192~!!0</CloseCmd>
<CloseCmd>^C^C^C~!!0</CloseCmd>
<CloseCmd>TC 1!TS 1</CloseCmd>
<CloseCmd>TN 2,0!TN 2,0</CloseCmd>
<QuietTime>0</QuietTime>
<Enabled>1</Enabled>
<XmitEnabled>1</XmitEnabled>
<ProvidesNMEA>0</ProvidesNMEA>
<RFtoISEnabled>1</RFtoISEnabled>
<IStoRFEnabled>1</IStoRFEnabled>
<MyCallNot3rd>0</MyCallNot3rd>
<BeaconingEnabled>1</BeaconingEnabled>
<BeaconPath></BeaconPath>
<BulletinObjectEnabled>0</BulletinObjectEnabled>
<DXEnabled>0</DXEnabled>
<DXPath></DXPath>
<MessagesEnabled>1</MessagesEnabled>
<MessagePath></MessagePath>
<TelemetryEnabled>0</TelemetryEnabled>
<TelemetryPath></TelemetryPath>
<!--DigiXform-->
</RFPort>
<!--RFPort[0]-->
A few notes: 1) the name of the port is up to you (KAM) in this case. Your COMM port will also vary depending on your configuration. Since I am using a Serial to USB dongle, I have a rather high COM4 number. Most native Serial ports will be 1 or 2. The big difference between the KPC and the 9612 are the commands to get into KISS mode. For the 9612 the commands are "Int KISS" and then "reset" The difference between the lines "reset" and "restart" escaped my notice the first time, so be careful.
After my script was working, I was able to get the KAM to start putting stations on the map. I checked this by disabling the Internet connection for a bit and clearing the station list. Eventually the digipeaters starting giving me data that got the stations through my 2 meter rig and 9612 and to the software.
The next stage of this will be getting a SCS tracker online with Robust Packet on 30 meters to pull in the long-haul stations. I just have to see if I can run two USB modems without things getting all sideways.
73
For the last two years or so, I have also had a portable station, N1ZZZ-7, on the air in the form of a Yaesu VX-8. Again, when walking around with an H-t on your belt and a rubber duckie, your signal isn't going to get too far, but it sometimes manages to get my signal out to digipeaters.
I have been fortunate here in the Wilkes-Barre, PA area. While standard packet is almost non-existent, the APRS system is very strong, especially along the I-81 corridor. There are several Digipeaters as well as a capable I-Gate to send the signals into the Internet for all to see.
What I have never done in all of these years, has been using APRS in it's most interesting incarnation, and that is with a fixed station, with a "real" TNC, and a mapping display to show where all of these beacons are.
This past week, I finally found a program that suited my needs and worked with the equipment I already had. The program was APRSIS32. The program was an easy download and installed quickly. The program connected to the APRS servers via the WiFi port in my computer and immediately started to download maps and place beacons on the screen through the IGates. The next step was getting my GPS to talk to the program.
I have a Garmin GLO GNSS receiver that connects via a Bluetooth link. This little receiver uses both the American military's GPS system and the Russian governments GLONASS constellation. Getting this device to talk to the APRSIC32 program proved to be a very easy. I turned on the GLO and enabled the GPS via Bluetooth in the program and it immediately found a fix. Not only did the program display my position both in Lat/Long, but also gave me a grid locator. The station's speed (0 at this time) is also prominently displayed on the screen. Most interesting to me was that the program also displayed the number and status of satellites in both the GLONASS and GPS systems. Even with my GLO on my desk near the window, I am getting better than 20 satellites in the list. These satellites' geographic position are also displayed on the screen as they float on by.
Getting my Kantronics 9612 TNC hooked up proved to me more difficult. The TNC needs to be in KISS mode, but I also use it for normal packet, so I can't get the 9612 "stuck" in that mode. I needed the program to start the 9612 in KISS mode, and then return it to Terminal mode when the program exited. Kantronics TNC's are a bit fussy in my experience and this proved to be no different. I knew that the computer was able to talk to the modem because I was able to use the AirMail dumb terminal was able to get me command prompts, but the APRSIC32 was not able to find it properly. While the program claimed that the radio port was active, it would not key the TNC or get any packets from the radio.
The problem is in the XML script located in the local folder where APRSIC32 is situated. This is a far cry from the plug-and-play software that is the norm today. To fix this problem, I had to do some internet research. The program's wiki talks about the lines for a Kantronics KPC, but not the 9612 specifically. In the interest of sharing the data, I will post the script from my XML file here so that anyone who needs it can cut and paste and get it working.
<!--RFPort[0]-->
<RFPort Name="KAM">
<Protocol>KISS</Protocol>
<Device>COM4:9600,N,8,1</Device>
<RfBaud>1200</RfBaud>
<OpenCmd>^M~</OpenCmd>
<OpenCmd>^M~</OpenCmd>
<OpenCmd>XFLOW ON!!0</OpenCmd>
<OpenCmd>FULLDUP OFF</OpenCmd>
<OpenCmd>INT KISS!!0</OpenCmd>
<OpenCmd>RESET!!0</OpenCmd>
<CloseCmd>^192^255^192~!!0</CloseCmd>
<CloseCmd>^C^C^C~!!0</CloseCmd>
<CloseCmd>TC 1!TS 1</CloseCmd>
<CloseCmd>TN 2,0!TN 2,0</CloseCmd>
<QuietTime>0</QuietTime>
<Enabled>1</Enabled>
<XmitEnabled>1</XmitEnabled>
<ProvidesNMEA>0</ProvidesNMEA>
<RFtoISEnabled>1</RFtoISEnabled>
<IStoRFEnabled>1</IStoRFEnabled>
<MyCallNot3rd>0</MyCallNot3rd>
<BeaconingEnabled>1</BeaconingEnabled>
<BeaconPath></BeaconPath>
<BulletinObjectEnabled>0</BulletinObjectEnabled>
<DXEnabled>0</DXEnabled>
<DXPath></DXPath>
<MessagesEnabled>1</MessagesEnabled>
<MessagePath></MessagePath>
<TelemetryEnabled>0</TelemetryEnabled>
<TelemetryPath></TelemetryPath>
<!--DigiXform-->
</RFPort>
<!--RFPort[0]-->
A few notes: 1) the name of the port is up to you (KAM) in this case. Your COMM port will also vary depending on your configuration. Since I am using a Serial to USB dongle, I have a rather high COM4 number. Most native Serial ports will be 1 or 2. The big difference between the KPC and the 9612 are the commands to get into KISS mode. For the 9612 the commands are "Int KISS" and then "reset" The difference between the lines "reset" and "restart" escaped my notice the first time, so be careful.
After my script was working, I was able to get the KAM to start putting stations on the map. I checked this by disabling the Internet connection for a bit and clearing the station list. Eventually the digipeaters starting giving me data that got the stations through my 2 meter rig and 9612 and to the software.
The next stage of this will be getting a SCS tracker online with Robust Packet on 30 meters to pull in the long-haul stations. I just have to see if I can run two USB modems without things getting all sideways.
73
Monday, May 13, 2013
Pactor II verses Clover II
In the early 1990's DSP chips finally became financially feasible and two DSP based, phase-shifted modulation modes became available to hams. Ham developers in the USA and Germany separately developed two HF digital modes that combined high data transfer speeds while remaining fairly robust and capable of maintaining point-to-point links over the HF radio spectrum.
The two modes were Clover and Pactor II. Implementation of the phase shift modulation was slightly, different, but these two modes were generally the same speed and claimed nearly equal robustness in the face of low S/N ratios.
I have always been a big fan of both of these modes and have used both since about 2003. These modes have be upgraded over the years, but the version two of these modes have always been very good for keyboard links.
Recently I was on the air with Pactor II with VE1XL. Conditions were poor with large fades in the path. Even the robust Pactor II was having some trouble moving data. It was still good enough for keyboard work, but the fades caused several error messages going back and forth as the data packets did not make it. Given that these were adverse conditions, I suggested to VE1XL that it would be a nice opportunity to test Clover and Pactor head to head.
We ended our Pactor link and switched to our DXP-38 Clover modems. These are the latest of the Hal Clover II modems and gave the mode the best chance at keeping a link.
We were able to establish the link, but we had trouble with the data blocks. Unlike Pactor, Clover uses what it calls Clover Control Blocks. These are sent at a modulation scheme that is the most robust it can muster. Unfortunately the CCB's modulation is not available for data packets. This proved to be the deal breaker on this link. Despite some error packets, the CCB's managed to get through, but as soon as the data packet tried to make it through, it was not able to get there.
Sadly eventually the link failed and we had to go back to Pactor.
So what shall we make of this? While I still find Clover more fun to operate due primarily to the fact that it has a more effective semi-duplex paradigm, and the ability to exchange station data on both ends of the link, it still needs more power to keep the S/N ratios up to the point where data can make it through. Pactor is a superior poor link mode, and this is a common consensus.
73
N1ZZZ
The two modes were Clover and Pactor II. Implementation of the phase shift modulation was slightly, different, but these two modes were generally the same speed and claimed nearly equal robustness in the face of low S/N ratios.
I have always been a big fan of both of these modes and have used both since about 2003. These modes have be upgraded over the years, but the version two of these modes have always been very good for keyboard links.
Recently I was on the air with Pactor II with VE1XL. Conditions were poor with large fades in the path. Even the robust Pactor II was having some trouble moving data. It was still good enough for keyboard work, but the fades caused several error messages going back and forth as the data packets did not make it. Given that these were adverse conditions, I suggested to VE1XL that it would be a nice opportunity to test Clover and Pactor head to head.
We ended our Pactor link and switched to our DXP-38 Clover modems. These are the latest of the Hal Clover II modems and gave the mode the best chance at keeping a link.
We were able to establish the link, but we had trouble with the data blocks. Unlike Pactor, Clover uses what it calls Clover Control Blocks. These are sent at a modulation scheme that is the most robust it can muster. Unfortunately the CCB's modulation is not available for data packets. This proved to be the deal breaker on this link. Despite some error packets, the CCB's managed to get through, but as soon as the data packet tried to make it through, it was not able to get there.
Sadly eventually the link failed and we had to go back to Pactor.
So what shall we make of this? While I still find Clover more fun to operate due primarily to the fact that it has a more effective semi-duplex paradigm, and the ability to exchange station data on both ends of the link, it still needs more power to keep the S/N ratios up to the point where data can make it through. Pactor is a superior poor link mode, and this is a common consensus.
73
N1ZZZ
Monday, April 1, 2013
Experimenting at 461 THz
I went on YouTube ( http://youtu.be/pvj3KDp8Ae8 ) and found a simple circuit that allows modulation of a pocket laser pointer. These red, 650 nm devices (461 THz) can be AM modulated with an audio transformer that varies the intesity of the light. The modulated signal can then be demodulated by a solar cell directly wired to earphones (where voltage is directly related to light intensity.)
I went to my local electronics store and got my parts. The solar cell was $5 and the audio transformer was about $3. Depending on the laser pointer, most are 4.5V, you will need a 4-cell battery holder (I used AA-sized) and jump out one of the slots. My laser pointers are 3V so I opted for a 2-cell holder. The AA cells are larger capacity than the button cell or AAA cells normally used to power these pointers, so should offer enhanced life per cell during use.
The trouble I am running into with this experiment is that the audio transformer has significant impedence on one side. Depending on how you wire it, you are attenuating either the laser power or the input audio. The spec is 72 ohms on the input coil and 0.62 ohms on the other coil. If you choose to attenuate the laser, your range is greatly diminished (my lasers are rated at < 0.5 mW). If you attenuate the audio, you need much more audio drive into the circuit.
While driving the input is easy enough if you are using a music device such as an MP3 player, it is more difficult if you are using a microphone. The solution will have to be another circuit with an audio amplifier to add to the audio I wish to drive the circuit. Unfortunately, my initial experiment had insufficient drive to generate the necessary signal.
So tomorrow it is back to the drawing board (and the reference books) to make myself an audio amplifier that hopefully can be rated at 3 V so that I don't need another set of batteries.
73
I went to my local electronics store and got my parts. The solar cell was $5 and the audio transformer was about $3. Depending on the laser pointer, most are 4.5V, you will need a 4-cell battery holder (I used AA-sized) and jump out one of the slots. My laser pointers are 3V so I opted for a 2-cell holder. The AA cells are larger capacity than the button cell or AAA cells normally used to power these pointers, so should offer enhanced life per cell during use.
The trouble I am running into with this experiment is that the audio transformer has significant impedence on one side. Depending on how you wire it, you are attenuating either the laser power or the input audio. The spec is 72 ohms on the input coil and 0.62 ohms on the other coil. If you choose to attenuate the laser, your range is greatly diminished (my lasers are rated at < 0.5 mW). If you attenuate the audio, you need much more audio drive into the circuit.
While driving the input is easy enough if you are using a music device such as an MP3 player, it is more difficult if you are using a microphone. The solution will have to be another circuit with an audio amplifier to add to the audio I wish to drive the circuit. Unfortunately, my initial experiment had insufficient drive to generate the necessary signal.
So tomorrow it is back to the drawing board (and the reference books) to make myself an audio amplifier that hopefully can be rated at 3 V so that I don't need another set of batteries.
73
UDR56K-4 Digital Radio
Well I've been following this UDR56K-4 Radio since it was introduced at Dayton last year. While it was promised for late last year, it is now expected to ship late this year. Today they offered it up for pre-sale. I ordered a pair of them for digital comms, including Winlink or D-star (DV and DD) on the 70 cm band.
The price around $400, but I am guessing this will rise as they are running into cost over runs and the real inflation is there so if you want one at their pre-order prices, you had better order one soon.
Some background, and ordering information is available on their blog: http://nwdigitalradio.com/
73
N1ZZZ
The price around $400, but I am guessing this will rise as they are running into cost over runs and the real inflation is there so if you want one at their pre-order prices, you had better order one soon.
Some background, and ordering information is available on their blog: http://nwdigitalradio.com/
73
N1ZZZ
Thursday, March 7, 2013
Pactor in the Pacific
I was able to spend a bit of time on the radio during my last voyage. It was a new ship for me, and my third command. The ship is a container carrier named the CAPT STEVEN L BENNETT. She was ending her US Navy charter and I was tasked with bringing her to the shipyard and getting her ready for commercial service.
I joined the ship in San Francisco, California and brought her to the yard in Singapore. This would be a voyage of at least four weeks so there would be plenty of time to get on the air.
Since I was the captain, I had a nice office near a window just under the bridge. I was able to run coax and a remote tuner control cable out through a pre-existing hole near my porthole and up to the bridge rail. On the rail I mounted my Icom AH-4 remote tuner and ran about 10 meters of wire in a sloping configuration to the top of the INMARSAT dome mast on the starboard side of the ship. I was able to tune from 40 to 6 meters with this wire which was about 25 meters over the water. I grounded both the rig and the tuner directly to the ship's hull, which is about the best ground you can get.
My rig consisted of my old standby mobile rig, the now aging Icom 706 MKIIg. I had a small switching power supply and for digital comms I had my Rigblaster NoMic for soundcard modes and my SCS DR-7800 P4 Dragon modem. The latter is THE box for Pactor, outperforming all comers in pactor comms.
Most sailors tend to use Pactor solely for moving email over the Winlink 2000 system. I cannot deny that much of my Pactor time was spent moving email to my friends and family via this system. While the INMARSAT system was certainly faster and more reliable, I like using radio and enjoy moving the personal mail over this system. I was able to make links nearly every day first from US West coast stations and then Alaska, and finally China and Russia. I was able to make Pactor III links the entire time, and speedlevels ranged from SL 1 on the weak links to SL 6 when I was fairly close. I had only 1 SL 6 link when I used the PTC-IIe and that was from a very nearby station. With the Dragon, the average link was SL3 (1400 bps) with several miles of distance between myself and the shore station, with several links being SL5 or SL6 (about 3600 bps).
The only time I had issues with WL2K was in the South China Sea. While there are several nearby shore stations, I had a devil of a time accessing them as soon as I entered the Sea. This continued all the way to Singapore.
I did not only use the Dragon for email however. I was able to work US and Canadian stations on Pactor well West of the Hawaiian islands. I was impressed with the robust nature of pactor. Most of these links were Pactor 2, but I did have some Pactor I and Pactor QSO's as well. We did not tend to move files during these QSO's but rather just text sent in the blocks that happens with the TOR modes. A bit closer to Asia I was able to work a few Japanese stations as well as a gentleman in Thailand. Unfortunately, I was never able to work any Australians on Pactor, and only a couple on SSB.
I was also able to get on PSK31 a few days and even worked some 10 meter SSB, although I am not too partial to voice these days. What is really fun is seeing how the change in location (about 350 miles a day) did to propagation. An area you worked yesterday just fine, will no longer be coming in, and a new area you haven't heard yet, will come in no problem.
I did try to take a listen and even called CQ on 6 meters, but the band wasn't open, so no joy in the VHF part of the spectrum.
It was a good trip as far as radio went, and we will see how it goes next time out there.
73
Jeremy
Subscribe to:
Posts (Atom)