rnd(): Ghosts in the Air Glow, Networking Woes, Surprise T-Shirt, Opal Receipts & Parking Tickets

It’s been another busy week, as usual, but I guess it’s nice to be occupied. You wouldn’t want to be bored … so I thought it would be a good time to make this “random” post that covers some things that have happened this week and accumulates thoughts from months back that I haven’t had the time to put into writing.

Ghosts in the Air Glow

This week saw the transmission of the Ghosts in the Air Glow program, a transmission artwork from A/Prof Amanda Dawn Christie (@magnet_mountain). Supported by the Canada Council for the Arts, it uses the High Frequency Active Auroral Research Program (HAARP) transmitter in Alaska as a shortwave radio transmitter, generating airglow, exploring the Luxembourg Effect and transmitting audio, morse code and SSTV images to listeners. This first series of transmissions are transmission tests, with final transmissions to occur in 2020.

Transmissions occurred over four days:

  • 26 March 2019 – 0030-0130UTC
  • 27 March 2019 – 0200-0300UTC
  • 28 March 2019 – 0800-0900UTC
  • 29 March 2019 – 0600-0700 UTC

Frequencies used were mainly lower frequencies, including 2750, 2800, 2820, 3200, 3150, 3350, 4400, 4500, 5100, 6900, 7900 and 8000kHz with a variety of different beams and directions. Transmissions were sent over two frequencies simultaneously during parts of the program.

The dates and times proved to be good – on the whole, they were all during waking hours in Sydney which made monitoring easier for me. Unfortunately, however, the choice of low frequencies limited the possibility of reception at home as propagation of such low frequencies during the daytime is nearly impossible. However, I did have the ability to use publicly available KiwiSDRs and kiwirecorder.py to do unattended monitoring.

I provide links to .WAV audio recordings of the transmissions as labelled – please be patient as file sizes are large and the server bandwidth is limited.

Day 1 – 26 March 2019

The transmission on Day 1 was around local lunch-time at work, but I had a meeting which complicated the process of reception. As a result, I wrote a few scripts to attempt reception over nearby receivers in the target areas that have good signal to noise ratios:

  • KPH (California, USA)
  • VA6DX (Alberta, Canada)
  • VE6SLP (Alberta, Canada)
  • aprs.fi (Kuopio, Finland)
  • IZH (Izhevsk, Russia)
  • R3TIO (Nizhny Novgorod, Russia)
  • KK6PR(Oregon, USA)
  • WA7HL (Washington, USA)

Unfortunately, it seems that network connectivity issues resulted in many of the recordings being corrupted with blocks of noise. Another issue was that some of the receivers may have been running settings incompatible with the kiwirecorder.py resulting in the wrong sample rate being written to file and a corrupted recording. Unfortunately, as I was at work, I had to wait until I got home before I could process them and put in my report.

On the whole, the reception was only considered borderline successful, with an evidence of the signal in the upper frequencies from KPH and KK6PR and some evidence of intermodulation in the SSTV.

I was also able to receive the story in NATO Phonetic Alphabet:

“My grandfather found a thing in the woods. A box with cameras hanging from a parachute. It came from the CIA. The DND took it.”

Recorded audio files from Day 1:

Day 2 – 27 March 2019

Reception on the second day was during regular lunch hours, so it was possible to run reception interactively which would avoid issues with kiwirecorder.py compatibility. Instead, I would have to change frequencies manually. I didn’t note the last minute change to 2820kHz on this day, instead, tuning to 2800kHz and missing the lower transmission.

My strategy was to receive from as many receivers in Alberta, Canada as possible, as it is a location with good reception – thus I used VA6DX, VA6OK, VE6SLP and VE6HFD. Unfortunately, I suffered a number of connectivity difficulties with the exception of VA6DX resulting in broken recordings. This was not surprising since Canada is half-way around the world from me, but I wouldn’t have estimated the hop count to be approaching 30!

Reception continued via KPH and KK6PR, with the addition of ArcticSDR in Kongsfjord, Norway to the mix due to poor signals from Russian-based SDRs.

Tuning in slightly late, I was able to receive most of the Morse in the beginning as:


I also received the Morse at the end, although with some severe fading resulting in loss of words:


As I’m not proficient in Morse code, decoding these messages took a lot of time and effort.

Recordings of reception from Day 2:

Day 3

Reception on day 3 was much more fruitful because its timing was just after sunset in Australia meaning that reception in the Pacific region would be possible. The later time also meant that I would be home to receive the program, allowing for a more concerted effort at reception. The choice of having just four frequencies meant I could have one receiver parked on one frequency while the other changed between the remaining three frequencies to catch the whole program.

Reception was attempted via KPH, VA6DX, SDRBris (Brisbane, Australia), ZMH292 Northland Radio (Bay of Islands, New Zealand), Marahau (New Zealand), AI6VN (Maui, Hawaii) and via my equipment at home (Icom IC-R75 + Wellbook ALA-1530L). The timing also meant that many of the receivers chosen were relatively quiet and almost idle, meaning I could have my two slots with no risk of locking other people out.

Unfortunately, reception from home was also possible on the upper frequency of 8000kHz, with very noisy images. Reception elsewhere was much better.

Audio Recordings from Day 3:

Day 4

Due to absolutely annihilating my LTE quota on the previous reception, I took a more measured approach, receiving via VA6DX and AI6VN only, as the time of transmission didn’t seem to favour too many other known-good sites. A last minute variation from 3150kHz to 3350kHz caught me off-guard resulting in the loss of part of the program, but again, signals were quite good.

The lost sentence of Morse code was also decoded as:


Audio Recordings from Day 4:

I also assembled this nice animated GIF from all my SSTV images:

In the end, I was able to monitor all four days of transmission with some successful reception on all days. In the process, I spent many gigabytes of my own LTE quota, by the third day, I finished reception with just 153MB of quota to spare, necessitating the change of service (and the networking woes which entailed). Had I not solved them in time, I could well have missed the final transmission.

I sent in a reception report for each of the four days in the hopes of receiving a QSL card. My first report has already been published – in time, the remainder of the reports will probably be published on A/Prof Christie’s website. I look forward to hearing the final transmissions in 2020.

Networking Woes

As I consider myself someone that’s rather educated about networking (running my own VLANs at home with multiple WANs and smartswitches), it’s a little surprising to have some networking woes. The most recent one in my past was thanks to Microsoft and Intel, with the last major Windows 10 update breaking Intel Advanced Networking Services (ANS). My solution was to go “hardware” and have three NICs each connected to a smart-switch port that would do the VLAN tagging/untagging. To come to this configuration, I used an HP NC360T that I bought from Hong Kong aka Intel PRO 1000PT Dual Port Network Adapter. The NIC was already in my box for a year and things were going well for several months …

Then suddenly … the computer began to stutter while playing music. The mouse pointer and even video would freeze mid-playback for seconds … every half a minute or so. At first, this was cured by a reboot … then it became persistent.

I started my investigations by looking at the Event Log which gave a good clue:

“The network interface “Intel(R) PRO/1000 PT Dual Port Network Connection” has begun resetting. There will be a momentary disruption in network connectivity while the hardware resets. Reason: The network driver detected that its hardware has stopped responding to commands. This network interface has reset 67 time(s) since it was last initialized.”

I did notice that the adapter occasionally disappeared from the machine after resuming from hibernation. There was a good correlation between when the system stuttered and this message appearing in the event log. The numbers kept incrementing the longer the system remained running – while it’s good that drivers have error recovery routines to try to recover from transient faults, having the routine disrupt the functioning of the rest of the system is slightly irksome. Maybe the adapter is faulty?

To try and flesh out the hypothesis, I grabbed another NC360T from a box where I knew it was working fine under Windows 7. Swapping the card into my main desktop, surprisingly there was no change to the symptoms. It seemed not to be  hardware fault with the card.

I uninstalled the drivers and allowed Windows to reinstall the “most appropriate driver”. Same problem. By now, I figured that it wasn’t worth fighting – maybe it’s another “Windows 10” thing … after all, Intel did not support the adapter under Windows 10 and relied on the “gimped” Microsoft driver that had no Intel ANS support.

If not, it was probably going to be something even more sinister – perhaps chipset partial failure of a PCIe transciever. Unfortunately, as I had no other free x4 slots to swap cards in/out of, I couldn’t check if that port was at fault. But since I was in no immediate need for the port, I would probably just remove the NIC and leave the slot empty for now which would be fine as long as no other parts of the system malfunctioned.

Instead, I thought I would revert to the previous configuration using my on-board Intel NIC to run multiple VLANs because, surely they would have fixed the compatibility problem from December, right? Actually, no, they haven’t yet … and they won’t until April/May. But they do have a workaround that stops ANS from crashing and allows VLAN configuration by Powershell – something I had attempted prior but wouldn’t actually work because I didn’t uninstall/reinstall ANS as they had instructed. To do this, I installed the latest Intel Proset Ethernet drivers on their website.

Getting out an Admin PowerShell, it’s possible to configure the VLANs using their instructions, but I found it strange that you refer to the adapters by name rather than by ID … that’s where copy and paste comes in handy. Needless to say it worked … for all of five minutes.

After that, Windows 10 decided that my latest drivers from Intel’s website were worse than the older drivers they had bundled, and replaced the drivers silently thus undoing all my configuration! I was back to VLAN-less operation. Luckily, repeating the PowerShell commands under the older drivers did restore the VLAN adapters. Phew.

To stop Windows being such a stupid-head when it comes to drivers, I’ve had to resort to a Group Policy edit, but only time will tell if that actually solves the issue or not.

But just when you think this was the end of the woes, think again! After literally destroying my LTE quota with KiwiSDR-based radio reception (uncompressed, of course) and uploads of recordings, I had to change SIMs to take advantage of (yet another) introductory offer. It was then, something unusual happened:

In case you were wondering – no, I wasn’t dialling up to the internet! The SIM was from a provider I used quite a bit and I was previously able to pull about 100Mbit/s through it. That suddenly fell to under 100kbit/s. But the uploads were still a semi-healthy 6Mbit/s.

The first step was to reboot everything in the house. Did that change anything? Nope. Second step was to try a different speed-test service … but it concurred with the slow speeds. Was it the provider? I swapped SIMs to a rival provider, and received just 250kbit/s – well short of the expected 30+Mbit/s.

Then I decided to divide the network to identify the cause. I did a speed-test from the phone and received a nice 100Mbit/s down. I then tethered that via USB to my laptop, which received about 40Mbit/s down – still miles faster.

This pointed the problem squarely at my beloved Mikrotik hAP ac. I had recently upgraded to RouterOS 6.44.1 without incident using the onboard package manager, but cycling the USB link seemed to result in the slow download. I checked my configuration, removed some fluff, disabled/re-enabled the lte1 interface with no change. I suspected the firmware was at fault, so I downgraded to RouterOS 6.43.13 (Long Term Support) and immediately, everything came back to normal!

While I could send a support request with a supout file to them, I couldn’t afford the downtime to investigate. But at least, I found a solution which worked.

To add the icing to the cake, the Xiaomi Redmi Note4X I rely on for my LTE-WAN now has a swelling battery … which is rather risky but may be a result of having the battery at a high state of charge and high heat due to the constant power-on use of the LTE radio and being upstairs for better reception in the summer season that just passed. Unfortunately, due to its design, battery replacement isn’t exactly easy … and neither is the screen or USB-port which is wearing out as it was bought second-hand with a cracked screen just for use as a modem. Maybe it will soon retire when I finally get NBN service.

But changing to the NBN is proving to be a bigger consideration that I first thought – very few carriers offer a static IP address which makes serving stuff from home a little difficult. Of those that issue dynamic IP addresses, quite a few are quietly migrating to carrier-grade NAT due to IPv4 address exhaustion. This is devastating for serving – it is nigh-impossible to do, but also subtly breaks many protocols. The price is also not exactly cheap, not compared to the <$5 “introductory” LTE SIMs I’ve been using for months on end. Unlimited high-speed access is better, granted, but the difference between $5 and $60 is quite a bit too. Some providers have gone under, quite spectacularly, so with something as important as internet service, cheaper-prices and static IPs aren’t on offer from the biggest names – not for residential anyway, and when they are, the prices are not exactly cheap.

Being on LTE I’ve had the displeasure of having CG-NAT and two NATs of my own in the way (one in the mobile phone, one in my router) just to get everything online. I’ve had to contend with one-way VoIP calls from time to time because of funny NATs and the way their ALGs work. But it only happens with one provider and not another. Likewise, I’ve had FTPS break, but on a different provider, while it works perfectly with the others. CG-NAT adds a layer of unreliability for anything but “regular” casual TCP-based outbound connections. I thought that moving away from LTE would remove the variability of airtime contention and CG-NAT … but it seems that CG-NAT may be here to stay.

Sometimes they say you can opt-out of CG-NAT, but you’re still stuck with dynamic IP. What happens when the pool runs out? Will we queue for addresses like hurricane evacuees queue for petrol? The IPv6 situation seems equally dire – not many providers make it clear whether they route IPv6 at all. I suspect they don’t.

Maybe the only way out of this mess is to get a VPS with a static IP to “bounce” connections through or use a VPN/overlay networks for much the same reason. The problem? Now we’re consuming even more resources, have to pay for the VPS/VPN, potentially have another point of surveillance and reduced performance due to greater risk of congestion and greater latency due to more hops. I don’t think I want to have to do this.

Oh how I wish I had FTTP when it came out … back then, some providers gave out Static IPs for free as if they had too many of them and users often didn’t fully appreciate the importance of it. Now, even if we do get a Static IP bundled in the plan, I wonder how long it will be before they “change their mind” and migrate everyone to something else. After all, Aussie Broadband migrated dynamic IP users to CG-NAT.

One often overlooked downside of CG-NAT is that you’re more likely to see CAPTCHA challenges visiting websites, as the “high load” and probability of having an “abuser” using the same public IP address is higher. There is a potential that access to certain sites would be blocked as well, as some CG-NAT public IPs could end up on block-lists. I’ve had this happen where access to the Bureau of Meteorology via Telstra became impossible.

Surprise T-Shirt #2 from element14

This week saw another surprise package from UPS, from our friends at element14. No doubt, this one’s for me, with my name on it!

Inside is a dark grey T-shirt, printed by Custom Ink on Gildan Heavy Cotton, Made in Nicaragua.

Compared to the last shirt, this one has a lot less text but it’s promoting the element14 Presents page which focuses on project video content. No no … not presents as in gifts.

Here I am wearing the shirt, accompanied by a very rookie Photoshop job to save you from seeing my extremely cluttered room. Maybe the lack of a proper workshop/studio space is among the reasons for not entering the video content space. Maybe that might change in the future – but for now, I’ll sit behind the comfort of my keyboard.

Public Transport Stuff – Waratah MkII, Malfunctions, North-West Metro, Opal Receipts

It’s been a while since I’ve reported on public transport related observations – but I’ve been spending more time on trains than ever. It seems that the old silver trains may well be on their way out now that the Waratah Mark II trains have been running.

Sporting a distinctly orange front with “eyeliner” black accents, the train is quite similar to the original Waratah.

The nameplate below the doors sports the Downer branding.

Interior passenger displays are now LCDs rather than LEDs, although this one shows basically the same stuff as the old LED displays would, even using an ugly yellow to do so. Perhaps a higher contrast Black/White or more readable font would be nice.

There is a larger LCD display also as you go up/down into the body of the carriage. This one displays both station information as well as certain promotional adverts. Other than this, the train sounds and feels very similar with only minor refinements. Somehow I think I’ll miss the old trains once they go.

As usual, malfunctions in the transport network seem to be the norm. The lifts at Schofields are a whole bucket of fun – serviced by Kone, they appear to be generic MRL lifts which aren’t coping well with the load. Landing call buttons not working … not nice.

But even worse is the one that goes from the over-bridge to the bus interchange – this one often stops short of the upper landing, sometimes enough to lock-out the lift. I suspect maybe there’s something wrong with a positioning encoder or programming of the controller – I’ve even witnessed it relevel under the load of 11 passengers, which isn’t something I’d expect for a lift that services just two levels. Rope stretch shouldn’t be an issue … perhaps there’s slipping through the sheave?

I came across an M-set leaving Liverpool that had no interior carriage lights and it only came on from time to time. Then I came across another M-set from Schofields that wouldn’t stop announcing “Doors Closing, Please Stand Clear.”

The big news for the transport network will be the arrival of the Sydney Metro. Slated for mid-2019, no firm opening date has been given (to my knowledge) but test runs have been run and the premier recently was on-board during her re-election campaign. It will be our first metro-style line with driverless operation and it’s not far from where I am, so it would be interesting to see how well it performs, especially with people who are inclined to hold doors open. The service frequency sounds great, but reliability is not certain.

It seems that it will be treated “as a train” on the Opal card system. This suggests there won’t be intermodal transfer benefits between the Metro and the train (assuming my understanding is correct).

Visiting Rouse Hill in late January, it was clear to see the transport interchange was being re-developed, with the over-ground Metro station looks very schmick with a lot of glass. I look forward to riding it once it opens – I’m sure some of those on the Epping to Chatswood Rail Link might look forward to the elimination of StationLink buses.

Readers may know that I’m not a fan of auto-top-up or online top-up due to the occasional misfiring result in “pending collection” problems. As a result, I’ve stuck to topping up at the stations using the vending/top-up machines. Interestingly, there seems to have been a change to the firmware of the newer machines that sets the top-up options to a maximum of $80 to allow for “Tap-and-Go” top-up, speeding the queues in the morning. Older machines still allow up to $120 which requires PIN entry. But this was the first time I actually topped-up with cash and it’s interesting to see the difference in the receipts. The cash receipt is much shorter, but surprisingly omits the TfNSW ABN. I wonder why? Without an ABN, I wonder if this is a valid receipt

Lets just say, while public transport has its perks, the recent windy and rainy weather hasn’t been the best.

Parking Meter Tickets

Love them or hate them, it seems that paid metered parking is becoming the norm in many local councils amongst the congested city centre areas. While I do have a license, I don’t drive, instead opting for public transport all the way, thus I don’t have to worry about expensive parking, but it seems some people do feel rather strongly about it.

Being in the Liverpool area because of my work, I frequently pass by their Duncan Solutions parking meters. These meters seem to get a lot of work, as the council does offer free 15-minute parking but only if you get a free ticket from the machine as proof. As a result, often I come across expired tickets littering the road.

Then I thought … well, surely there’s not much to a parking ticket, right? Actually, there is more than meets the eye.

The tickets they issue are on thermal-paper stock that prints black text on a blue coloured background print. The printed text includes a meter ID number, date/times, price, ABN and another ID number at the top.

The rear of the ticket has a black clock track which helps the equipment determine when to “cut” the ticket. There seems to be an ID number on parts of the white space, but not every ticket has an example of this – this one says 31212806180350. The text warns you to place the ticket with the other side up on the dash, printed in a screen-dithered pattern.

The first thing that I noticed was the presence of an anti-copy pattern – when copied with a device that has auto-contrast/auto-toning, the word “copy” comes out as in the above image.

This type of protection seems to work on the fact that when the auto-contrast increases the brightness of the image, the smaller dots “disappear” whereas the larger dots get smaller, resulting in the word “COPY” appearing. But the original has approximately the same density of ink despite the different dot diameters, hence the word is not as easily legible to the eye.

The paper stock also has a zig-zag pattern (highlighted by hand in red) as well as some places where the larger dot density seems to “thin out” in lines. I wonder if this is a special pattern, similar to Anoto paper where the pattern is unique enough to identify the location on the roll (hence protecting against manipulation) or whether it is just a simple diagonal stripe pattern (see the wider shot for scale).

A closer look near the bottom edge shows that the last line is actually a form of microprinting – it spells out the name of the company that manufactures the paper stock, ColleaguesNagels.

I didn’t find any fluorescent ink when putting the ticket in front of my UV-A LED and there were no visible watermarks in the paper stock. I tried soaking the ticket in water but no secret messages appeared.

Picking up trash along my way to the station, I came across this unusual service print-out which says “CB INSERTION”. I wonder if that stands for “coin box” or something else? (Circuit Board? Circuit Breaker?)

I also came across this meter which seems to have crashed and wouldn’t start-up properly. I wonder if the watchdog eventually reset the unit or maybe it was stuck due to a lack of power (as these are often powered from solar panels on the top of the meters and an internal battery).


It’s been a busy week – but it’s been a rather interesting one. From receiving artistic shortwave radio transmissions from a scientific research facility, to solving network problems, unpacking T-shirts, observing public transport and inspecting parking meter tickets closely, it’s been a rather long posting. I hope to receive the QSL card and feature it on this site soon.

About lui_gough

I'm a bit of a nut for electronics, computing, photography, radio, satellite and other technical hobbies. Click for more about me!
This entry was posted in Computing, Radio, Telecommunications, Travel, Uncategorized and tagged , , , , , , , . Bookmark the permalink.

2 Responses to rnd(): Ghosts in the Air Glow, Networking Woes, Surprise T-Shirt, Opal Receipts & Parking Tickets

  1. Your mention of CG-NAT addresses being blocked sounds like my VPN problems with being blocked from some mainstream sites (usually with misleading or no error messages) or having to pass CAPTCHA tests – usually multiple times (very annoying). Since I also use NoScript, surfing the web gets complicated sometimes.

    Add to that, a particular VPN server’s access will be restored, probably due to complaints, and then blocked again next week!!??

    • lui_gough says:

      Indeed, VPN users experience the same grief when they come out of endpoints sharing the same IP address as possibly hundreds of others. Only the higher-end VPN plans or VPSes will offer a dedicated IP that isn’t shared with others, so sites don’t spuriously block you for suspicious behaviour because of high load or a single bad actor/malware infected machine sharing that IP.

      – Gough

Error: Comment is Missing!