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!

 

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.

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 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 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).

Implementation

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.

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.

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.)

 

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.

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).

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!