ESP32 – Stock Firmware Disables JTAG

I’ve been working on a project recently with the ESP32.

I purchased 4 raw ESP32-WROOM-32 modules from Digi-key, soldered them to my hardware, and then attempt to flash them over the JTAG interface. Every attempt of programming the module left me with the dreaded all ones seen blah blah blah error.

Error: JTAG scan chain interrogation failed: all ones
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: esp32.cpu0: IR capture error; saw 0x1f not 0x01

All of the existing documentation online suggested a hardware fault so I went into hardware troubleshooting mode until I became fully confident the hardware was not an issue. After much thrashing around, I finally noticed the module were pre-programmed as it was dumping data over the UART port. I managed to re-flash the hardware using the UART interface instead and then the JTAG interface was accessible.

This left me with the following understanding:
1. It’s possible for the firmware to “brick” the JTAG interface
2. ESP32 modules from espressif can potentially come with firmware pre-installed.

I’ve posted to the Espressif Forum here:

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 the difference in the pass regions.

[Update]: The squiggles are entirely related to the calibration setup. The antennas supplied with a fixed coaxial cable which is huge no-no when performing VNA measurements unless the cable itself it attached during the calibration.

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.



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. 

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.