miniVNA Tiny

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:

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.

VNA Comparison #1

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.

VNA Comparison #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.

VNA Comparison #3

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.

VNA Comparison #4

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.


Transmission Loss Test

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.

Transmission Loss Plotted
Screenshot from 2019-03-09 16-22-23
Tabulation of mean, standard deviation, min and max of the transmission loss measurements. These measurements range from 1MHz to 1.5GHz. 

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.

Reflected Loss Test

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 🙂

Reflected Loss Plotted

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



IdeasX Alpha Manual

I’ve been working hard to make IdeasX deployable for testing in a real world environment. I’ve also be cleaning up the code based to make it easier for others to hopefully join in on the fun. Attached is the user-manual for the IdeasX Alpha.

If you believe you’d be interested in helping or have potential users please don’t be afraid to contact me.

User Manual:

Demo Video:

I say “ummm” five million times. You’ve been warned. 

CC3220, FreeRTOS, Debugging, and Hairloss

It’s been quite a while since I’ve seriously worked on or written anything about IdeasX. The project has been placed on hold for a few months now. I’ve recently graduated school and I’ve been working on a few things in my personal life. I’ve decided to dedicate a few hours each week to the project to see where it will go. My time is limited thou as I need to spend slightly less than 24×7 hours behind a laptop screen.

I’ve causally and not so casually made a few decisions during my hiatus:

  • I would like to switch the IdeasX embedded devices to an RTOS platform. MCU are going to continue to embedded multiple processors and radios. I’m confident all future embedded devices will be running a scheduler / RTOS (for better or worst). Porting to an RTOS will simplify code development, and teach me a few new skills. This way I can keep up with my jack of all trades master of none.
  • If I’m going to be spending only a few hours a week doing development, I need to be developing on a platform that allows me to actually get things done. A polished development environment which will give me debugging capabilities and quality code.
    • The ESP8266 is not exactly the ideal solution to this. There is a FreeRTOS SDK, but the debugging features of the device are not well documented.
    • I’ve managed to develop a sketchy makefile / shell script setup which permits me to do basic debugging with a GDBstub and compile with FreeRTOS. I still need to develop / port a MQTT library to RTOS. Unfortunately, not all the SDK commands for the ESP8266 are available in the FreeRTOS SDK. Porting and testing is also … really really un-fun.
    • I’ve been considering using a part from the TI SimpleLink line: ideally, the CC3220. The SimpleLink line is completely code portable (in theory), and I’m required to learn it for work anyway. The sad bit is the chip costs more than the entire ESP8266 with a flash chip, all the RF components, and a shield.

Gesture Recognition: The Beginning

I’m been working on a debug mode for the IdeasX v0.3.1 sensor module to send back live accelerometer (XL) and gyroscope (G) from the LSM6DS3. The idea is to have the encoder send data back to a computer to be remotely processed. (The final design will have the module locally processing the data every 100ms.) The purpose of this is two fold:

  1. It will permit me to rapidly develop and deploy different gesture recognition / motion detection algorithms using a high level language such as Octave or Python before deploying them on the module.
  2. The methods developed for streaming data can later be used for training applications. Example: if a significant motion algorithm is selected to activate an actuator, an initial configuration dialog will stream the data back allowing the therapist to see the range in XL and G values. The therapist would then adjust the thresholds for significant motion according to the range in values of the data streamed back.

Design / Guesswork

The LSM6DS3 utilized by the V0.3.1 module contains a 8kB FIFO which can be used to store information generated by the device (accelerometer, gyroscope, and temperature). When raw IMU data is going to be used for adaptive switching, the FIFO will permit the ESP8266 to process the data in chunks freeing up processing time for other operations.

The normal order of operations would be some like what follows:

  1. Set the IMU to the desired sampling rate.
  2. Configure the FIFO to trigger an interrupt on INT1 when the desired number of samples is reached.
  3. When the interrupt is triggered, the ESP8266 will dump the specified number of samples used for the sense period.
  4. The ESP8266 will process the data by applying a detection algorithm (NN, DTW, etc)
  5. If the detection algorithm has detected an event, the ESP8266 sends a Data Message through the IdeasX system.

For streaming information, the following debug order of operations is proposed:

  1. Set the IMU to the desired sampling rate.
  2. Configure the FIFO to trigger an interrupt on INT1 when the desired number of samples is reached.
  3. When the interrupt is triggered, the ESP8266 will dump the specified number of samples used for the sense period.
  4. Repeat step 3 for X number of times then proceed to 4
  5. The ESP8266 sends the raw data via a Data Message through the IdeasX system.

Due to limited FIFO size and various sampling rates, a few plots were generated to determine the number of samples which would be accrued over 4 different proposed sampling periods (50ms, 100ms, 150ms, 200ms). “Sampling period” here refers the amount of time the LSM6DS is allowed to accrue samples before being dumped.

Figure 1: Samples vs ODR

The first figure displays the number of samples accrued based on the sampling rate of the IMU or output data rate (ODR) and the length of time samples are allowed to accrue. It should be noted each sample is actually 12 bytes total. Each axis for the accelerometer or gyro is represented by two bytes. The resolution can be reduced to 1 byte per axis. As the response time of the module should be <200ms, a 200ms sampling period can be ruled out as too long.

Figure 2: Time required to dump FIFO based on ODR.

Figure 2 displays the amount of time required to dump the FIFO. This was based on experiments which recorded the amount of time required to dump a single sample from the IMU and store that sample in RAM.


Figure 3: It requires 8us to receive 32bits from the SPI port and to store it into an array.

Figure 4 displays the number of bytes the LSM6DS3 will attempt to store in the FIFO based on the 4 evaluation periods. The black horizontal line represents the limit of the 8kB FIFO. The simulation assumes the gyro and xl are both storing samples for each axis with full resolution (16 bits).

Figure 4: Bytes!


The v0.3.1 module required a tiny modification. A jumper needed to be soldered to attached INT1 to PBA. This also required a modification to the GPIO ISR routine to check if the interrupt was triggered by the LSM6DS3 or the pushbutton. Basically, the ESP12 has NO GPIO lines. I had to double up functionality.

Figure 5: I soldered a 0R resistor to R33 shorting PB_Ax to INT1

The final settings had the LSM6DS3 sampling at 208Hz. The ESP8266 would dump the FIFO every 100ms and store it into a buffer. This would repeat 10 times and then I simply dumped the buffer into an MQTT message instead of first formatting it for a Protobuff. Note…this was a feasibility test. I modified the ideaX-sniffer tool to plot the data using Qt. You can see a short screen capture of me plotting the data here.

ideasX_sniffer_20160924.mp4 - VLC media player_071.png
Figure 6: Plotting XL data from v0.3.1 module over WeeeeFeeeee (Wi-Fi).

There is much that needs to be done to make this viable. The data needs to be packaged. There needs to be additional commands made to set the sampling rate of the XL and G remotely along with the threshold of the FIFO to trigger an interrupt. It might be easier to simply make a command to send byte X to address Y out of the SPI bus. The ideasX-sniffer tool also needs to be updated of course to support the new commands, but luckily that is super easy : D.

…then the fun with signal processing begins (muhaha, j.k. I have no idea what I’m doing.)


RTL-SDR (Part I)

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.

Selection_052.pngHere 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.Selection_056.png

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.

What the *$@& is IdeasX?

If you follow me on anytype social media, you’ve likely seen some bizarre pictures with wires and scrolling code. I’m hoping it instilled feelings of awesomeness and confusion, like those (got milk?) commercials which vanished into the ether in the late 90s. Anyway, to the pointy bit, I’ve been developing a system designed to connect severely disabled students with C.P. to computers and other electronic devices (AKA the Ironman suit I’m after hours at work, shhh).

The original picture of me was rated PG-13 sooo

If you’d like to understand what the hubbub is about, how it works, and why I’m doing it or maybe just make fun of my spelling, feel free to checkout the IdeasX pages on this website. (Only one page is completed)

If you find any of this interesting and would like to join forces or if you happen to find my explanations particularly confusing, feel free to contact me!