Author: curiousmuch

I’ve recently been forced to work on an antenna matching issue at work which has been fun and terrifying at the same time (my favorite combination personally). See, I don’t have any traditional RF experience. Everything has been learned on the job / via independent studies; therefore, there I have quite a few gaps I’m trying to fill.

I purchased a miniVNA Tiny to continue my studies at home: http://miniradiosolutions.com/

The miniVNA tiny  runs between $350-$600 dollars which is two to three orders of magnitude less than a traditional professional VNA new or used. That being said, I didn’t expect much. The best part was I didn’t even really know what to expect because I didn’t know what was important :).  I thought measuring the reflected power on a few antennas I had laying around would interest people.

VNA Comparison

At work we have an Agilent E5071C (running Windows XP) with the ECalibration kit (yaas). The green traces are the miniVNA and blue is the Agilent device.

The first two antennas are monopoles which came with a RTL-SDR based SDR. I’m guessing they’re aircraft bands? The measurements between the two VNAs are quite close. The antenna base is a mag-mount which I placed on the most hearty ground plane I could find.  This was my most repeatable test. These sweeps are from 100MHz to 1.2GHz The other tests have the antenna support via a cardboard box sitting on top of the same ground plane. They consist of sweeps from 100MHz to 3GHz.

I don’t like the squiggles in the miniVNA measurement. I’m not sure what the cause is or what to call them? Increasing the calibration points in the range of measurement did not seem to improve the measurement. I believe the Agilent’s output power is higher, but I didn’t see a difference in measurements when I dropped it to -20dBm. I believe whatever these squiggles are caused the difference in the band-pass region for #2.

The next two antennas are in the 900MHz / ISM band. I believe their results are quite respectable. You can see a spike around 1.5GHz. It was impossible to remove this with calibration and averaging. It’s advertised the dynamic range of the miniVNA is suppose to be 50dB at 500MHz. I would like to know how to measure the dynamic range for it’s entire operating range so I could estimate if my intended measurement is impossible.

The forth comparison is quite different. It’s likely my fault as this was quite an ad-hoc setup and performed on my lunch break.

Dynamic Range Testing

I put 10 seconds of thought into how I could measure the dynamic range of the miniVNA when measuring transmission or reflected powered, and I thought I figured it out. I decided I would use a variable RF attenuator.

For the transmission measurement, the RF attenuator was placed between the DUT and the DET ports.  The lost should be equal to the set RF attenuator and remain flat across the spec’d range for the attenuator (so I assumed). The attenuator I was using was spec’d from DC to 1.5GHz.

 

Luckily, I was right for once. The plot’s legend lists the amount of attenuation selected in dB. The x-axis is frequency, and the y-axis is power measured at the DET port. The following tables shows some basic statistics from 1MHz to 1.5GHz. There appeared to be a constant 0.3 to 0.24 dB error.

For the reflected measurement, the RF attenuator would be placed between the DUT and a calibrated short. I assumed the response would be flat for range of the device. I didn’t quite know what the loss would be for a set attenuation setting.

I didn’t expect what I saw tho. The plot’s configuration below is the same as the previous.  At first you can see the loss is double or higher than the set attenuation, which I’m guessing it due to the reflected waves having to travel down the attenuator twice. As the attenuation increases, the loss becomes highly frequency dependent. I assumed this was due to an issue with the miniVNA, but the E5071C showed similar behavior. My current guess is terminating the attenuator with a short, which is not 50ohms, is causing strange behavior or I have an issue with one of connectors. This also might be normal, because I’m a dummy 🙂

That’s all for now. Let me know if you have any thoughts and things you’d like to see measured!

 

This morning I visited my favorite coffee shop and decided to fool around with my RTL-SDR T.V. tuner. I’ve used it once before to decode the information sent via my car’s fob. At the time, I was interested in attempting to crack how the “code” sent to my car was encoded, but I was quickly discouraged by the level of encryption. Jamming the TX to a car and then replaying it later is a much more effective method.

This morning I was simply exploring the functionality of it again in preparation for spurious signal detection on a job site later in the week. I loaded up GQRX and took a look around 900MHz and I found a few cool FM signals.

Here you can see what I believe is FSK signal at 930MHz. I recored the audio using a narrow-band FM demodulator and opened it in Audacity to see if I could see any data / preambles / or sync periods for the receiver. Amazingly, I could!

Here you can see what a believe is a preamble followed by a sync period for the receivers clock. Pretty wild! I’ll zoom into the data right after the sync period now.

The preamble  appears to have a period of 27ms which is approx. 37Hz followed by the sync period which is 1-2ms (audacity isn’t really built for this and isn’t giving a ton of resolution). This means the data is being clocked at around 1 – 0.5 kHz. Not blazing fast by any means.

Interestingly, this is later followed by a sync period with an identical clock and then another which appears to double the clock. I’m guessing the transmitter sends some basic information at a low data rate for receiver’s with a crappy RSSI and then additional information for those with a decent RSSI value.

I decided to extend the clock through out the signal w/ Pinta (the Linux version of paint) to see if I could determine the encoding scheme (NRZ, Manchester, etc). As expected, I literally have no idea what I’m doing and extending th clock didn’t really reveal anything to me. I would expect the data to sampled on either the rising or falling edge, but appears to be needed on both edges for to detect some of edge transitions. Manchester / Bi-phase is kinda outta the question right away based on the length of some of the pulses.

I think when I get some time and I’m tired of IdeasX, I’ll build a receiver in GNUradio which will sync sampling based on the edge transitions, examine common encoding techniques, and then bust this thing. I tried to open an existing NFM receiver design, but it appears to be using some dated blocks.