I once had a site that I used for collecting information around radios and communications. I’m now recreating it here. Please stay tuned as the old articles will likely start showing up once I have had a chance to go through all the old information and figure out what’s still good and what’s old and crusty.
SWL Logs for the week of 2021-01-02
2021-01-03 – 19:45 – Radio National da Amazonia – 11910kHz DRM
A very good music program in Poruguese broadcast using DRM (Mode B) from Parque do Rodeador, Braslia, Brasil. Heard via SDR in Santa Domingo, Dominican Republic. Nearby AM signal was causing some dropouts. Adjusting receive frequency up 0.12 kHz seemed to help. SINPO 54555
2021-01-03 – 20:50 – China Radio International – 6020kHz
A personal favorite of mine, Chinese music via AM. This program was destined to the Polish-speaking community of Europe although heard very well in Mardshegy, Hungary. There did seem to be some sort of TTY signal near the carrier that caused some interference but did not take away from the overall experience. SINPO 54555
2021-01-05 – 14:14 – Denge Welat – 11540kHz
Music program. Lost signal at 14:30. SINPO 35433 in Wien, Austria.
2021-01-05 – 14:40 – All India Radio – 11560kHz
Music program with what appears to be news mixed in. According to documentation I can find online, this is being transmitted from Bengaluru. SINPO 45544 in Wien, Austria.
2021-01-05 – 16:30 – China Radio International – 5970kHz
Music program with news in German. SINPO 55555 in Lutsk, Ukraine.
2021-01-05 – 16:46 – China Radio International – 6040kHz
Singing music program. Not my favorite but it was a nice program. SINPO 55555 in Lutsk, Ukraine.
2021-01-05 – 17:00 – Radio New Zealand Pacific – 9780kHz DRM
Supposed to be DRM to the Pacific Islands but I’m not getting a full lock on the signal using any of the SDRs on the [New Zealand] island. Signal looks strong with no adjacent signals. Did hear a blip of audio at the top second.
2021-01-05 – 17:10 – Radio New Zealand Pacific – 9780kHz DRM
Music and Apollo 13 BBC story. Finally found the audio! No joy using SDR in Brisbane (no signal at all) but a great signal in Hawaii (AI6VN/KH6 using 75m Beverage antenna). DRM Mode B. Really enjoy the text being sent along with the audio:
16:50 - 18:35 9780kHz
18:36 - 19:58 11690kHz
QSL www.rnzi.com
SINPO 55555 in Hawaii
2021-01-05 – 20:13 – China Radio International – 6020kHz
Traditional Chinese music. Another day of great traditional music (with Polish introductions). Tried a receiver in Poland but transmission is noisy there. Signal is very clear in Fuzesabony, Hungary. SINPO 55555.
2021-01-05 – 20:58 – Tech Note
49m band is quite crowded at his hour. Seeing 6010, 6020, and 6030 all in use simultaneously (including a DRM signal!). All signals seem to be clean and no problem with selectivity on the receiver.
2021-01-05 – 21:00 – Radio Romania International – 6030kHz DRM
French program. Tried a receiver in Hungary but SNR is too low. Showing 17.7dB in Buchen, Germany (DM7RM). SINPO 55555.
2021-01-06 – 02:30 – WRMI – 9395kHz
60s, 70s, and 80s music program. Great signal in Alexandria, Virginia. SINPO 55555.
2021-01-07 – 20:00 – China Radio International – 6020kHz
I’m really starting to like this music program beamed to Europe from China. Traditional Chinese music with very good signals. Receiver used today was a KiwiSDR in Maroshegy, Hungary. SINPO 44544.
Posted in Shortwave Listening
Tagged Brazil, China, China Radio International, Radio National da Amazonia
Comments Off on SWL Logs for the week of 2021-01-02
Starting my GridMaster after a long hiatus from the birds
It’s been a while since I’ve been active on the birds. So long that when I started adding my grids to the Grid Master map many of them are from paper cards! I mean, who does that now days?! Going through those cards, though, brought back a lot of good memories from the past including cobbling together gear to work AO-16 back when it spontaneously came back to life and standing in the parking lot at Dowdy-Ficklen Stadium at East Carolina University waiting for AO-51, SO-50, and AO-27 to come by. Ahh, yes, the good times.
Here we are at the beginning of December, 2020, at 8.81% of the grids filled. We’ll see what it looks like in a month.
Posted in Satellite Operations
Comments Off on Starting my GridMaster after a long hiatus from the birds
On the air from Charleston, SC (EM92, FM02, and FM04)
We stayed in quarantine for much of November to make the trip down to Charleston to see family we haven’t seen in more than a year. It was a small affair but good for the soul. What else is good for the soul? Satellite passes!
While in town, I tried to work every good SO-50 and ISS pass that came overhead (AO-91 still eludes me for some reason, I can’t hear myself on the downlink). Since I have been off the birds for so long, I think I made most every mistake a rookie could make. But, in less time than it takes to tie my shoe, I had corrected my problems and put stations in the log. I even roved over to Folly Beach to activate a not-quite-rare-but-still-needed grid (FM02) which is also an IOTA contact! Of course it was raining at the time and there were issues.
We also stopped on our way back north to snag an ISS pass in FM04. I was hoping it would be in FM15 but we didn’t leave in time and Lumberton, not Wilson, was where we crossed paths with the bird. For those of you needing FM15 and FM16, I will very likely be back “home” later in December and will be happy to give out FM15 and rove over to FM16.
This is really the first time I have been back on the birds in many years. Sure, I’ve picked up my antenna and made a few contacts here and there but I haven’t really been active during the past ten years or so. I do love anything to do with portable operations so this obviously works well for me. We’ll see if it sticks this time.
Thanks to K4KDR, WI7P, KG4AKV, N8URE, N5BO/R, N4THC, N9KT, N3CRT, and N1RCN for answering my calls. I’ve got you in the logs and you should have already received a QSL via LoTW if you do such things. If I can find my QSL cards, I shall have something in the mail to you as well.
73 for now.
Coastal Linking Network: A thought experiment in replicating the Coastal Linking System for data.
John, KE4TZN, and I were discussing the idea of replicating the Coastal Linking System in DMR. The difference being that the existing network uses audio linking where DMR, and other digital modes, use an IP-based network for routing the links.
IP networks, not to be confused with Internet-connected networks, switch data between networks without degrading the quality of the data. Switching audio, however, results in degrading audio quality and, thus, cannot be repeated indefinitely.
The existing network
Generally speaking, the existing network uses a core analog voice repeater and other analog voice repeaters use a separate radio, a link radio, to route the repeater’s audio to that core repeater. This allows users of a repeater to send their audio across their local repeater, across the link radio, to the core repeater. The core repeater then repeats that audio to any other link radio that is listening which would then direct the audio to its repeater. This is a traditional star network. This type of network has several advantages and disadvantages, including a big disadvantage of the core repeater being a single point of failure.
One benefit of the existing links, that will become apparent shortly, is using a frequency of 440MHz and a bandwidth of 15kHz.
Replicating the network
The network has connections from Columbia to:
- Ahoskie
- Bath
- Buxton
- Elizabeth City
- Englehard
- Greenville
- Hertford
- Williamston
All sites could be connected to Columbia except Buxton and Greenville. Buxton, being a high priority when hurricanes threaten, absolutely needs a good connection back to the mainland. Greenville is also a target city as there are resources there that would be good to link to, including the regional trauma center.
Because we don’t have to worry about degrading our audio (it’s all data after all), we can daisy-chain links together to create paths to more distant locations. Buxton, not reachable directly from Columbia, becomes connected via the Englehard site. Greenville also joins the network but through Williamston.
A bonus to using a routed network is we’re no longer required to stick with that star configuration. You’ll notice a lot of links (lines) on the map that don’t connect back to the Columbia site. These links not only relieve the stress on the Columbia site handling all of the traffic on the network but also provides alternate routes for the traffic to flow. In an IP network, these links are constantly being weighed to determine the lowest cost path for moving data from one point to another. If data is moving between Buxton and Bodie Island, two hops, there is no reason to send it via Columbia (three hops). However, if one of the links between Buxton and Bodie Island is congested or has failed, the data can flow through Englehard and Columbia to route around the issue. These changes in routing happen automatically.
Headaches with the design
The difference between amateur radio, and basically any other radio service, is that amateur radio systems (and networks are no different) are generally built where it can be built where commercial and public safety systems are built to satisfy a specific need. If you were to overlay the North Carolina Highway Patrol’s microwave network on top of what I have laid out you would see that we aren’t using half the sites they use. You’ll also see that they use multiple altitudes and frequencies at each site to make sure their statewide network stays up and operational. They have a slightly larger budget that I (we) do.
Another issue is that all of these links are currently setup with 5GHz in mind. There are other bands available to amateur radio operators including a nice, quiet piece of spectrum in the 3GHz area that could be used. Using other bands might improve bandwidth and throughput.
The Greenville site being used in this model is actually the NC Highway Patrol tower that we currently don’t have permission to use. Of course we don’t have permission to hang any of this new gear on any tower so why not shoot for the Moon and ask for it all, right?
The frequencies we’re talking about using attenuate significantly in air. Add moisture and we’re talking about the possibility of a link dropping. Hopefully any link degradation would likely mean a reduction in available bandwidth and not a complete link failure.
The last issue I had was trying to remove the star configuration, and somewhat failed to do. I ended up with two segments of the network that still need the Columbia site to connect to each other. The two segments generally break down to the “Beach” sites (Bodie Island, Buxton, Chicamacomico, Englehard, and Ocracoke) and the mainland sites.
So I have a network, now what am I supposed to do with it?
Well, the original idea was to have an independent network that would replicate the Coastal Linking System but for DMR. We can easily connect our DMR repeaters to this network and use it for backhaul to connect them to a regional c-Bridge-like device that would provide the connectivity to all repeaters on the network and also route traffic off the network to other DMR networks (Brandmeister, DMRVA, etc) to get access to outside networks. The required bandwidth for DMR is miniscule compared to the bandwidth that will be available on the links.
It would also be possible for DMR users that have their own hotspot devices to connect them directly to the c-Bridge-like device over the IP network and get access to the repeaters in the region.
There are also ways to connect analog repeaters together using this isolated IP-network. AllStar is one system that allows you to create your own network with their software, thus linking analog repeaters across the IP network.
APRS can also be used over the IP network. If all the IGates in the region were connected with an APRS server that was on the network, any messages and position reports could be routed to all other users that were also connected to the network (either on the IP network or in the area of the IGate that was).
Servers supporting email, webpages, keyboard and video chat, and file exchanges can also be put on the network much like packet radio BBSs used to be setup. Heck, if you wanted to stand up BBSs for users to connect to using traditional packet radio, the BBSs could connect to each other over the IP network and send and receive messages and bulletins using telnet.
The idea is, it’s all just data. The network doesn’t really care what the data is, it just wants to know where it’s going.
How do users connect?
So far we’ve only been talking about building the wide area network (WAN) that connects towns and cities together. This is not the network that users, or even servers and devices, interface with.
To do that, we’ll need to build out a local area network (LAN) or, maybe even a metropolitan area network (MAN) that will handle data going between users and between users and local resources.
In the image we see the city of Greenville with a light blue sector shaded in representing a LAN. We also see some example links established within that sector representing the Brody School of Medicine building, Pitt Community College, and a ham radio operator’s home. The idea of the LAN is that anywhere in that blue area you should be able to connect to the local network and use it to connect to whatever resources you may need whether that be a web server, a file server, or a chat room. And that server may be located in a server room at Brody, in someone’s home that is on the LAN, or on a server in Buxton.
LAN bandwidth can be much greater, supporting many more users, than that of the WAN so it would be best to have certain resources replicated locally wherever many users will be accessing the information. The WAN can be used to synchronize data between servers where speed isn’t a factor leaving a faster experience for the user.
Posted in Technical Thoughts
Tagged DMR, HSMM
Comments Off on Coastal Linking Network: A thought experiment in replicating the Coastal Linking System for data.
Managing resources during Public Service events using APRS
– photo by MotoPhotoMe.
Over the weekend I helped support the American Diabetes Association Tour de Cure; a two-day charity bicycle ride that allows riders to choose between 80 and 100-mile courses each day. I’ve been supporting this ride for many years now, and, thankfully, we’ve been using the same route for the last few years which makes it easier to come up with a communications plan each year.
Over the years I’ve watched other people’s techniques for managing resources. One guy kept his notes on a knee board and used some sort of shorthand notation that no one could figure out during the brief glances we were allowed. In years past I’ve enjoyed using a small whiteboard to keep track of where my Support and Gear (SAG) vehicles were. This year, however, I decided to do something a little different.
The Goal
The goal of my madness is to make sure I had SAG vehicles “patrolling” between rest stops where we knew bicyclists were located. The Raleigh Tour de Cure has six rest stops with those doing 100 miles doing a loop that takes them back through rest stops five and six before heading to the finish. Altogether, there are eight segments of race course that need to be covered. Each SAG is assigned a segment to run in a particular direction. In this way, it is hoped that a SAG will go past a certain point every ten to fifteen minutes (we don’t want a rider to have to wait a long time for a SAG). Luckily not all eight segments are occupied at the same time which reduces the overall need. This year we managed to do it with five SAGs, one doctor, one motorcycle SAG (who also had a photographer riding backwards taking pictures of the riders for MotoPhotoMe), and two shadows. We could have used more but this is a great crew, and everyone worked together as a team flawlessly.
Past Management Tool
Like I pointed out earlier, I used to use a whiteboard to keep track of who was where and to make assignments when a SAG made it to their next rest stop. My chart looked something like this:
RS | SAG
--------
S->1 | 1↑, 2↓, Last Rider
1->2 | 3↓
2->3 | 4↓, First RiderThis means that between the Start and Rest Stop 1 I have SAGs 1 (running backwards from 1 to the Start) and 2 (running forwards from the Start to 1), between Rest Stops 1 and 2 I have SAG 3, and between Rest Stops 2 and 3 I have SAG 4. I try to stagger SAGs going between the same rest stops to add patrol coverage. When SAG 1 reaches Rest Stop 1 the expectation is that they will call me on the radio and let me know they’ve arrived. I will then give them a new assignment (it could be patrolling back towards the Start line or moving on to Rest Stop 2). A
whiteboard makes it easy to make these updates and keep everything in order.
The benefits of using such a system is that it’s simple and easy to manage, allows a quick look to see your needs for coverage, and allows you to make other notes (e.g. who has already had lunch, special assignments, where is the lead and last riders). The drawback is that there is no record keeping with this system. You can’t go back and see who was where when. Keeping up with this information would require a completely separate form and would likely slow you down. Also, because all this information lives locally on a whiteboard there is no way to
share this information with anyone else if, for example, you need to step away from the radio for a few minutes.
Using APRS to manage the resources
This year I decided to use my APRS client, Xastir, to manage my resources. Some of the SAGs ran APRS trackers (thanks to the Raleigh Amateur Radio Society (RARS) for letting us use their trackers!) in their vehicles which meant I didn’t have to update their locations and I always knew where they were. The other resources I had I simply used objects on the map to track where they were located (approximately) and moved those objects when they provided an update. It looked something like this:
I could also put requests for service on the map (e.g. bicyclists that had contacted us via phone or SMS to say they needed assistance) and be reasonably sure I was sending the closest SAG to them.
Because I was the only consumer of this data (this year) none of the objects I created were actually sent over the air or to the Internet. I could have easily shared this information over the air or the Internet to others and I hope to do so in the future.
Oh, I should point out that one of the SAGs, Moto 1, used APRSDroid on his cellphone to provide his location. This was problematic as there were many places along the route that didn’t have any cellular connectivity much less sufficient data connectivity.
We also didn’t have sufficient APRS infrastructure to cover the entire route. This was mostly remedied by the addition of a tactical digipeater. I’m hoping to establish a new permanent digipeater along the route in the future.
What other benefits can APRS bring to the table?
Beyond keeping track of everyone’s location, either in semi-real-time or by moving objects around the map, APRS can provide information sharing to other stations that need to know what’s happening. By pushing objects to the network, one can inform all participants of resources and needs (this requires some sort of display to consume this information). Also, the voice frequency can be kept clear of routine requests by using the text messaging capabilities of APRS.
Record keeping can be done in a not-so-detailed way by having the APRS client record all traffic to disk. This means that every movement, addition or deletion of an object, and every message would be recorded. While not as detailed as formal messages, or even keeping a detailed log, it does provide some tracking that, if needed, might be helpful.
Conclusion
Using APRS to manage public service events could prove to be helpful. It doesn’t necessarily require buy-in from everyone involved but would benefit from others participating. I didn’t go into all the features that APRS could bring to the table but, rather, touched on the ones that
I felt were important. I’m hoping to extend this article in the coming months to bring more thoughts on the subject.
Thanks
I’d like to thank the volunteer hams that came out and participated in this two-day event:
roaming the rest stops.
John Snellen, AI4RT – SAG 1
RARS Public Service Coordinator
Wallace Smith, KJ4UKV – SAG 2
David Krum, NW3U – SAG 3
Joe Sheets, KJ4LZM – SAG 4
Bruce Buck, KC4UQN – SAG 5
Tom Byrum, N3TCB – Moto 1
Lubov Byrum, N3BOV – Photo 1
Dr. Scott Playford, KM4NWC – Doc
Bill Cole, KG4CXY – “Jim”
founder of Carolina Helping Hams
Mark Freeze, WD4KSE – “Zoe”
Notes
- Yes, I realize all the maps used in this article don’t contain roads and such. While this information was available to me I really didn’t need it as I had the route and rest stop data staring at me. If I needed the road-level maps they were just a couple of clicks away.
- The APRS network frequency, 144.390MHz, is quite busy and I wonder if building a separate network on a different frequency would benefit the event. Think ALOHA.
Posted in Public Service Events
Tagged APRS, Digital Operations, Public Service, Tour de Cure
Comments Off on Managing resources during Public Service events using APRS
DXpedition to Core Banks NA-067
A small cadre of hams invaded Core Banks (Portsmouth Island), North Carolina (NA-067) for the 2011 Islands on the Air (IOTA) contest as N4I. Although many others activated NA-067 from other islands that were much easier to get to, Eric W4OTN, Amanda KI4IWS, Bill KG4CXY, Leslie, and Robyn WA4WPD packed gear up in a few vehicles and took a boat over to the island where we took refuge in a rental cabin provided by the National Park Service.
Officially part of the Cape Lookout National Seashore, Core Banks is a strip of barrier island off the coast of North Carolina just south of Ocracoke Island and north of Morehead City. The cabin is actually a duplex; we rented both sides and used one for our radios while the other side held our food and sleeping quarters. Antennas included a dipole and a vertical loop that faced the Atlantic Ocean. Overall, signals were good and 111 contacts were made to 40 DXCC entities using phone, CW, and digital modes during the operating period. Unfortunately, we really aren’t contesters and spent more time conversing than transmitting as one could tell from the low QSO count. Overall we had fun operating which is what matters.
