Dual Band Rubber-Duck Antenna Testing (SWR)

I recently acquired a new wide-band SWR meter from Amazon, and I wanted to revisit the antenna tests I’d run in the past with my old 70’s 11m test equipment.

So, today I got together all of my the rubber-duck dual-band antennas, picked one of my ChiComm radios and took some measurements.

Here are the antennas I tested (left to right).

  • Nagoya NA-701
  • SaineSonic INF-641
  • Nagoya NA-771
  • Baofeng stock (long)
  • Baofeng stock (short)

Here are the results for my test. I ran each antenna 3 times in each band; at the lower phone boundary, upper phone boundary and close to the center of the band.

VHF Lo – 144.1 MHzUHF Low – 420.0 MHz
VHF Center – 146.0 MHzUHF Center – 435.0 MHz
VHF High – 148.0 MHzUHF High – 450 MHz
AntennaVHF(l)VHF(c)VHF(h)UHF(l)UHF(c)UHF(h)
NA-7012.19:11.83:12.44:12.18:11.17:11.31:1
INF-6411.79:11.09:11.37:11.08:11.02:11.77:1
NA-7712.39:12.20:12.21:12.08:11.16:11.97:1
Stock (L)1.59:11.03:11.02:12.07:11.07:11.15:1
Stock (S)2.76:12.18:11.79:11.09:11.59:11.70:1

I was really surprised by how well (from an SWR standpoint) the little SaineSonic that came with my GT-3TP was. I was also shocked at how bad the two Nagoyas seemed to be. There was a 6th antenna (not stock, or Nagoya) that was in the 3:1+ range across all the bands. Either it was damaged, a fake.. or maybe they are simply garbage.

These tests are hardly scientific. I did, however, hold the radios in free space away from me, instead of testing them on the bench surrounded by metallic objects.. for those about to try and drop some truth bombs on me.

Once I figure out a fair rig to install the antennas into, I’ll hook up my little nanoVNA and see what it has to say. Could confirm these results, or it could say something completely different. What I’d like to see from the nanoVNA are some gain estimates. The little antennas might match well, but do they also have good gain; that is an important question.

Relevance. What is Search Relevance?

Working in the Search sector for nearly a decade now, it would seem like this is an easy question to answer. However, to a degree, it is not. Why can it be such a vexing concern? As simply put as I can; it’s all in the context of the search, not so much the content.

You can (and should) build the more beautifully indexed body of content imaginable, but without relevance applied to a search, it’s use is limited at best. Identifying the context of the search is critical to determining the relevancy of the results.

A good example from a book recently read, illustrated the importance of relevancy signals to search. Take the case of two doctors searching the term ‘myocardial infarction’.

Doctor #1 is in his office, looking for recent research into the causes of sudden death from heart attacks. He’s most interested in the latest articles regarding predictive signals or other metrics that might more accurately predict the likelihood of an event in his patients.

Doctor #2 is in the ER, faced with a perplexing acute MI; and is in need of a procedure that will stabilize the patient as rapidly as possible. Perhaps there is a new class of drugs that can help, and he needs to know how to administer them, quickly, or even know if his facility caries the desired drug.

Both of these physicians may be searching on the same term, but they needs are strikingly different. Giving each of these doctors the right (relevant) results quickly can only occur with the application of signals. Signals might include the location of the search? Is it coming from a network in the ER, or the subnet in the offices? Are their other signals such as which doctor may be making the search? Some doctors are assigned to ERs, others may not ever rotate through. These are all signals that can impact the relevancy of a search.

So, how does the search engine know the context? It needs to be fed the signals so it can calculate the relevancy of each result to the search being conducted. These signals need to be identified and provided by an intervening layer that understands the context of the search. That context might be the geolocation or known assignment, or even the past search history of a specific user that includes information on which links they more often explore. All of these are signals that can be expressed to a search engine (or appliance) to improve relevancy.

How might these signals be expressed? Some examples, if I might diverge down a rabbit hole related to my own decade or so experience with Solr, would be applying boost formulas to specific fields containing results stored in certain fields or term sets in the body of content.

Perhaps for the ER doctor, documents with a field property of medical_procedure:myocardial medical_procedure:infarction would boost the score by a major factor, pushing how-to or other information to the top of the list.

In opposition to that, the other doctor’s search might look at boosting publication date (more recent, more boost) and other fields such as a flag indicating the content is research (e.g. research:true article:true). The way relevancy can be identified and improved will always require the application of some signals, of one type or another.

Other examples of signals that can be applied, might originate from the content curator. Any good search application needs to have SMEs (subject mater experts) and content curators continually updating the data and reviewing the results. Something a curator might do is apply a boost factor for products that are currently on sale, or have a ‘most popular’ rank that has recently changed. Maybe the product is over-stocked, or perhaps it was just discontinued. The curator is a critical pat of the relevancy solution. It can’t be left solely on the shoulders of the search engineering team to ‘guess’ that is relevant today, and what is not.

There needs to be a concentric circle of needs, so to speak, when considering the factoring and refactoring of the search (relevancy) solution. The layers (outer to inner) of this concentric feedback look might look like this.

Poor feedback / upset users / lost sales
Business and domain awareness
Content curation
Paired relevance tuning
Test-driven relevance.

The Takeaway

More important to a good search solution, and thus a good customer experience is a TEAM of people looking at the changing relevancy of content, tuning to meet the most urgent business and customer needs, and method of signaling the context of a search to ensure the most relevant results are returned, every time.

Stratux Active Ports

Dictionary of active ports found on a typical STRATUX ADS-B device.

Running nmap, between ports 100 and 48000, the following ports were found to be open on my STRAUX receiver:


Nmap scan report for 192.168.1.200
Host is up (0.0037s latency).
Not shown: 47892 closed ports
PORT STATE SERVICE
8080/tcp open http-proxy
9977/tcp open unknown
30001/tcp open pago-services1
30002/tcp open unknown
30003/tcp open unknown
30004/tcp open unknown
30005/tcp open unknown
30006/tcp open unknown
30104/tcp open unknown

STRATUX Port Mapping

Port Protocol Detected As Data Stream Contents
8080 tcp http-proxy HTTP 400 response
9977 tcp unknown JSON – Pi hardware data
30001 tcp pago-services1 no data seen on port
30002 tcp unknown TEXT – stream of hash/id strings

*20000FBF8811DA;
*8DA8B395E1160600000000E15133;
*8DAAF471591DA3F06975FD4FF289;
 
30003 tcp unknown TEXT – stream of ICAO ids in a message with timestamp and some Lat/Lon data

MSG,3,111,11111,A21F2F,...,10450,,,29.68991,-98.40042,,,,,,0
MSG,7,111,11111,A17D1A,...,3050,,,,,,,,,,0
30004 tcp unknown no data seen on port
30005 tcp unknown BINARY – unknown stream type
30006 tcp unknown JSON – stream of contact informtion with tail, squawk, Lat/Lon etc.

{“Icao_addr”:11064874,”DF”:0,”CA”:0,”TypeCode”:19,”SubtypeCode”:1,”SBS_MsgType”:7,”SignalLevel”:0.000378,”Tail”:null,”Squawk”:null,”Emitter_category”:null,”OnGround”:false,”Lat”:null,”Lng”:null,”Position_valid”:false,”NACp”:null,”Alt”:35000,”AltIsGNSS”:false,”GnssDiffFromBaroAlt”:null,”Vvel”:null,”Speed_valid”:false,”Speed”:null,”Track”:null,”Timestamp”:”2020-10-08T14:07:01.547Z”}
{“Icao_addr”:11425751,”DF”:17,”CA”:5,”TypeCode”:11,”SubtypeCode”:0,”SBS_MsgType”:3,”SignalLevel”:0.000388,”Tail”:null,”Squawk”:null,”Emitter_category”:null,”OnGround”:false,”Lat”:29.654480,”Lng”:-97.743935,”Position_valid”:true,”NACp”:null,”Alt”:17025,”AltIsGNSS”:false,”GnssDiffFromBaroAlt”:null,”Vvel”:null,”Speed_valid”:false,”Speed”:null,”Track”:null,”Timestamp”:”2020-10-08T14:07:02.319Z”}

30104 tcp unknown no data seen on port