Showing posts with label waterfall. Show all posts
Showing posts with label waterfall. Show all posts

Friday, February 10, 2023

"CQ CQ - Calling all dielectric welders!" (Or, those strange curvy things seen on a 10 meter waterfall)

 If one owns a receiver with a waterfall display, the increased cluttering of the 12 and 10 meter bands with weird "swooping" signals could not have gone unnoticed.  Take, for example, this recent snapshot of the lower portion of 10 meters from the waterfall of WebSDR #5 at the Northern Utah WebSDR (Link)

Figure 1:
10 Meters as seen on a beam antenna pointed toward Asia showing QRM from a large number of different sources - presumably dielectric heaters/welders/seamers.  These things radiate badly enough that they should have their own callsigns, right?
Click on the image for a larger version.

 

In looking at this spectral plot - which comes from an antenna oriented to the Northwest (toward Asia and the Pacific) one could be forgiven for presuming that someone had somehow connected a can of "Silly String" to their coax and was squirting noodles into the ionosphere!

What, specifically, are we looking at?

Across the entire spectrum plot one can see these "curved" signals, some of them - like that near the bottom, just above the cursor at 28374 kHz - are quite strong while there are many, many others that are much weaker, cluttering the background.  These signals contrast with normal SSB and CW signals - the former being seen clustered around 28500 and the latter around 28100 kHz - which are more or less straight lines as these represent transmissions with stable frequencies.

What are these from?  The general consensus is that these are from "ISM" (Industrial, Scientific and Medial) devices that nominally operate around 26957 kHz to 27283 kHz.  Clearly, the waterfall plot shows many devices outside this frequency range.

What sort of devices are these?  Typically they are used for RF heating - most often for dielectric sealers of plastic items such as bags, blister packs - but they could also be used in the manufacture of items that require some sort of energetic plasma (e.g. sputtering metal, etching) in any number of industrial processes.

Where are they coming from?

The simple answer is "everywhere" - but in terms of sheer number of devices, it's more likely that much of the clutter on these bands originates in Asia.  Consider the above spectral plot from an antenna located in Utah pointed at Asia - but then consider the plot below, taken at about the same time from an antenna that is pointed east, across the continental U.S. and Canada - WebSDR #4 at the Northern Utah WebSDR (link):

Figure 2:
10 Meters on a beam pointed toward the U.S.
Click on the image for a larger version.

 

To be absolutely fair, this was taken as the 10 meter band was starting to close across the U.S, but it shows the very dramatic difference between the two antenna's directionality, hinting at a geographical locus for many of these signals.

Further proof of the overseas origin of these signals can be seen in the following plot:

Figure 3:
Spectrum from AM demodulation of some of the signals of Figure 1 showing 50/100 Hz mains energy.
Click on the image for a larger version.

This plot was taken by setting the WebSDR to AM and setting for maximum bandwidth, tuning onto a frequency where several of these "swoops" seen in Figures 1 and 2 are recurring and then, using a virtual audio cable, feeding the result directly into the "Spectran" program (link).

As expected this plot shows a bit of energy at the mains harmonic frequencies of 120, 240 and 360 Hz owing to the fact that this antenna points into slightly-noisy power lines operating at the North American 60 Hz frequency - but on this plot you can also see energy at 50 and 100 Hz, indicative of a lightly-filtered power supply operating from 50 Hz power mains - something that is NOT present anywhere in North America.

Based on other reports (IARU "Intruder Watch", etc.) a lot of these devices seem to be located in Asia - namely China and surrounding countries where one is more likely to experience lax enforcement of spurious radiation of equipment that is manufactured/sold in those locales.

Why the "swoop", "curve" or "fishook" appearance seen in Figure 1?  If these devices were crystal controlled and confined to the nominal 26957 kHz to 27283 kHz ISM frequency range, we probably wouldn't see them in the 10 meter amateur band at all, but many of these devices - likely "built to cost" simply use free-running L/C oscillators that are accurate to within 10-15% or so:  As these oscillators - which are likely integral to the power amplifier itself (perhaps self-excited) - warm up, and as the industrial processes itself proceeds (e.g. plastic melts, material cures, glue dries) the loading on the RF output of this device will certainly change, and this results in an unstable frequency.

Why do they radiate?

Ideally, the RF would be contained to the working area and in the past, reputable manufacturers of such equipment would employ shielding of the equipment and filtering of power and control leads to confine the RF within.  But again, such equipment is often "built to cost" and such filtering and shielding - which is not necessary for the device to merely function is often omitted.

Can we find and fix these?

In this U.S. and parts of Europe such sources are occasionally tracked down and RF interference mitigated - either voluntarily or with "help" from the local regulator - but the simple fact is that the intermittent nature of these sources - and the fact that they radiate on frequencies that are prone to good propagation when the sun is favorable to such - makes them very difficult to localize.  If the signal source is coming from halfway around the world, there's likely nothing that you can do other than point your directional antenna the other way!

If it so-happens that you can hear such a signal at your location at all times of the day - regardless of propagation - you may be in luck:  There may be a device with a short distance (a few miles/km) of your location - and perhaps you can make a visit and help them solve the problem.

* * * * * * * 

Related article:

 

This page stolen from ka7oei.blogspot.com


[End]

Sunday, May 31, 2015

Adding a waterfall display to the mcHF transceiver

Figure 1:
The "Grey" waterfall mode of the mcHF self-contained SDR transceiver
in "Magnify" mode which shows only 24 kHz total bandwidth.
Three - possibly four SSB QSOs are visible in this picture.  This picture
was taken before I added windowing to the FFT, improving the "look".
One of the things that the mcHF SDR transceiver has been missing from the beginning was a type of spectral display often referred to as a "Waterfall" display.

It seems that all "good" SDR rigs have them these days - so why not this one?  When I first started working with the mcHF and contemplated this question I thought, "there's plenty of processor horsepower for this... I think..."

Actually, it was more complicated than that.

Two types of LCDs and interfaces:

There are two "flavors" of the mcHF:  The early units used LCDs with "SPI" (high speed Serial) interfaces while the current crop (and by far the majority) use a parallel interface that physically maps the display's RAM to the processor's I/O controller so that it sees it as RAM - plus, it can access the display's normal commands with 16 bit-wide parallel data - either method being orders of magnitude faster than the SPI.

Now, as new features are developed for the mcHF, it is strongly desired that they all be compatible with both the SPI and Parallel version.  To that end Chris, M0NKA kindly sent me an older "Rev 0.2" UI board with an SPI interface-type LCD so that I could spend some time improving the SPI-based routines that work with the display - plus it gave an opportunity to test both types prior to releasing software to make sure that I'd not "broken" anything on one or the other version of hardware.

Fortunately, after a bit of studying of the data sheets for the LCD unit I was able to discern that there was a hitherto un-utilized hardware feature that allowed bulk-writing to a defined area of display RAM and with this - and a few other tweaks - was able to speed the "user experience" of those with SPI interface mcHF transceivers by a factor of 4-10 or so, depending on what they were doing.  To be sure, the display updates on SPI-interface radios are still significantly slower than the Parallel-interface radios, but the former are very usable.

Rewriting the "Spectrum Scope":

Figure 2:
Rewritten spectrum Scope showing multiple SSB signals on
40 meters.  Signal-noise (band) conditions were rather poor, but
at least 3 QSOs (and possibly 5) are visible in this shot.
The 'scope is set to display the full 48 kHz mode and 10dB/division.
Note also that the transceiver is set to "LO Low Frequency Translate
mode which moves its demodulation +6 kHz from "zero", eliminating
the majority of issues that are encountered near "DC" with
typical "audio" SDR implementations that use
direct-conversion and/or sound cards.
This brought back another thing that I'd wanted to do from the beginning:  A complete rewrite of the Spectrum Scope (e.g. "Spectrum Analyzer").  I'd reworked it early on, adding some IIR low-pass filtering to "smooth" the display and adding a bit of non-linear display function so that its dynamics were improved, by the vertical scale meant absolutely nothing at all - in fact, its dB/division scaling varied depending on what else was on in the display's passband:  It looked "OK" aesthetically if viewed from a sufficiently long distance, but it did not stand up to close, technical scrutiny.

So, I completely scrapped the Spectrum Scope function save for the original RFFT written by Chris, the somewhat hairy and efficient display functions originally written by Chris and hacked on by me (this is open-source!) and I kept my IIR low-pass filter which seemed to be just fine.

When I was done I had a "proper" spectrum scope with the vertical scale adjustable from 5dB/division to 20dB/division and even 1, 2 and 3 S-Units/Division (because I could...)  There was even an AGC function so that the strongest signal was adjusted to be at the top of the scope, but at the same time it would detect the peak/average of the signals on the scope and prevent an "empty" span from rising up and simply filling the display with noise!

Not wanting to stop there, I put some thought into the waterfall display.

Adding a "Waterfall" display:

The waterfall display is the same as the spectrum scope, except that it adds the dimension of time:  While the frequency is represented horizontally along the "X" axis as with the spectrum scope, with a waterfall display the strength of the signal is represented by the color or intensity of what is on the display rather than the height.  The newest signal is "painted" along the bottom of the display and when the next scan is complete, the "old" information is scrolled upwards and the new information takes its place.  In this way, one has a brief history of signals - both on and nearby the center frequency.

There was a problem:  How do I do this without taking up massive amounts of processor power and/or memory?

As it turns out, all I really needed to store at any given time was the magnitudes and signals in the passband.  In "normal size" mode, the waterfall display is 70 pixels high and since it used a 512 point FFT (sort of...) I had 256 frequency bins, so I represented 48 kHz of bandwidth with 256 pixels horizontally with each pixel representing 187.5 Hz, nominally.  (Note:  It really doesn't work that way - read about FFT and windowing if you are interested...)   If all I wanted to do was store that information, I needed only 17920 bytes of storage since all I was actually storing was the same sort of data that the Spectrum Scope produced:  A signal that went from 0 for the weakest signal to 63 for the strongest - which would fit in a byte!  Making this a circular buffer with a pointer for each line, I could easily keep track of where I was in "time".
Figure 3:
Several CW signals (at least 5) shown with the Waterfall display
in "Rainbow" mode.  In this mode weak signals start at the "blue"
and of the rainbow and progress to red for the strongest.
(Pardon the garish colors and poor contrast - it's difficult to take a good
picture of an LCD screen with a cell-phone camera!)

For the color palette I did the obvious:  A 65 entry RGB palette that matched that 0-63 amplitude range:  That extra color?  I'll get to that in a moment...

The LCD actually uses a 16 bit RGB (5,6,5) color scheme, so it was easy to make another array into which I could simply load my color palette of choice.

Updating the display:

Updating the display was the slightly tricky bit.

Remembering that I'd implemented some "block write" functions when optimizing the SPI interface functions, I wrote some additional, minimalist functions to perform the needed tasks:  One to set up the area on the screen for the block write, another to accept data and another to "close" the block write and return the LCD to "normal" operation.

To display the waterfall, one simply defines the area of the screen defining the extent of the waterfall, enables the "write" command and then blindly throws the exact number of bytes of 16 bit RGB data at it constituting the size of the waterfall display.  It was a simple matter to use the stored amplitude data from the 17920 byte circular buffer to index the color palette and send that data to the LCD - I just had to make absolutely sure that I sent exactly the amount of data that conformed to the expected column and row sizes.

Since this was a "blind" write to the LCD it took an absolute minimum of I/O and even on an SPI interface LCD - while significantly slower than on a Parallel-interface LCD - it is still very usable!  Better yet, it doesn't take oodles, gobs and tons of processor power.

It does take more processor power to update the display than does the spectrum scope, particularly if one has it set to its highest speed, but in actual use one would have it set so that it would take 10-20 seconds for a signal to disappear from the display, and that really doesn't load the processor too much.  (Audio processing always takes precedence, so if one turns on all of the DSP modes with the waterfall set to its fastest mode, you will see it slow down significantly!)

About that "65th" color?  If you look carefully at Figure 3, above, you'll note a blue (cyan, actually) vertical line aligned with the "7035" graticule on the bottom of the screen to indicate the "tuned" frequency:  It's used for that!

Other modes:

In Figures 1 and 3 the waterfall is shown in the "Magnify" mode in which only 24 kHz is actually being displayed instead of the possible 48 kHz (I need to add a picture to show this...) and there is also a mode of the waterfall display that takes up more of the screen, covering the word "Waterfall Display".  There is also a "HotCold" palette in which weak signals are blue and strong are red - and it would be an easy matter to add even more palettes - if someone wants to go through and derive all 64 colors.
Note:  As of version 0.0.219.18, eight types of FFT windowing are available, significantly improving the "look" of both the spectrum scope and waterfall display! - For more information about this read the article on Wikipedia about Window Functions.  If one chooses the appropriate window function the waterfall display and spectrum scope's response to signals is much "tighter" as spillover energy from one "bin" to another on the screen can be minimized.

[End]

This page stolen from "ka7oei.blogspot.com".