Gas station without pumps

2017 September 2

Correcting reasoning on buck regulators

Filed under: Robotics — gasstationwithoutpumps @ 13:10
Tags: , ,

In More on cheap buck regulators, I wrote

We can fix the windup problem by either reducing the integrator coefficient (reducing the capacitor size on the COMP node, whose current size I’m uncertain of) or by using a larger inductor, so that the current changes less when the FET switches, and the time constant of the system is better matched to the integration time constant set by the RC value.

I was worried even as I wrote that claim that my reasoning was wrong.  Increasing the inductance would make the voltage on the output capacitor adjust more slowly, meaning that the system was even more under-actuated, resulting in more integrator windup. But I went ahead and bought some surface-mount 10µH inductors and put one on the board that I had taken the 1.5µH inductor off of.

In testing under light loads, the larger inductor works fairly well, though regulation is sometimes lost for short bursts even with a 145mA load.

resistance current 1.5 µH ripple 10 µH ripple
∞Ω 0 mA ±7mV ±18mV
40Ω 145 mA ±32–50mV ±36–45mV
32Ω 184 mA ±37mV ±36mV
24Ω 245mA ±60mV ±63mV
16Ω 374 mA ±50mV ±126mV
740mA ±65mV ±805mV
1388 mA ±435mV ±1186mV

So larger inductors give similar control at low currents, but hit the integrator windup problem at lower current levels.

I can think of two fixes:

  • Making the capacitor of the compensation circuit smaller, so that there is less integrator windup.  I’m not sure what that will do to the stability of the regulator.
  • Adding an LC filter to the output, to remove the ripple.  Because of the resistance of the inductor, this will entail some loss of efficiency.

I tried add a 1.5µH and 10µF low-pass filter to the output of the regulator, measuring current and voltage after the filter:

resistance current 1.5 µH ripple 10 µH ripple
∞Ω 0 mA ±7mV ±12mV
40Ω 146 mA ±3.6mV ±3.5mV
32Ω 185 mA ±4.3mV ±4.5mV
24Ω 246mA ±5mV ±8.5mV
16Ω 376 mA ±7mV ±12mV
740–760mA ±7mV ±194mV
5.3Ω 1090mA ±12mV–±220mV ±500mV
1388 mA ±314mV ±510mV

Adding LC filtering seems to be a big win, but the original 1.5µH inductor is still the better choice.  I get good regulation at 0.75A, but ripple starts gets big at 1.4A.  At 1A, I sometimes get a very steady output and sometimes a large 123kHz ripple, unpredictably

The voltage drop across the 1.5µH filter inductor is about 0.2V at 1A, so I’m losing about 3% in efficiency, but the 200mW loss is not enough to cause heating problems in the inductor.  For the application I’m looking at, I don’t expect continuous currents

Changing the compensation capacitor will be harder, as it seems to be an 1005 capacitor (0402 Imperial), which is a little small for my clumsy fingers and tweezers—changing the much larger inductor was enough of a challenge for my dexterity.  I don’t know exactly how many pF  the capacitor is, either, so I’d probably have to do a lot of trial-and-error fitting, or take the capacitor out and try measuring it not in the circuit.  Getting probes onto such a small part is going to challenging when it is not on a board.


2017 August 28

More on cheap buck regulators

Filed under: Robotics — gasstationwithoutpumps @ 18:40
Tags: , ,

A couple of days ago, I wrote about the cheap buck regulators I bought, and expressed some confusion about how poorly they were working.  I’ve spent a couple of days trying to diagnose the problem, and I think it is beginning to make some sense to me.

First, the parts are almost certainly knockoffs of the original MP1584 parts, since those parts cost over $1 in 1000s and the whole board was about 44¢ in 1s.  I’ve not been able to find a good photo of an authentic part, to see if the markings match. The only data sheet available is the original one, which may or may not describe the internals of this chip accurately.

Second, I unsoldered the inductor from one of the boards using a hot-air tool, and soldered on header pins for easy testing.  The inductor appears to be a 1.5µH inductor (though the picture on the website clearly showed a 4.7uH inductor).  The smaller inductor results in larger current ripple.  According to the datasheet, a 1.5µH inductor for a 6V output with a 12V input and 930kHz switching frequency would result in about a 2A peak-to-peak current ripple, and the peak current would be about 1A higher than the load current.  Since the part is supposed to have a maximum switch current of 4A, this is consistent with a 3A limit for the board.

Third, I reverse-engineered the board as best I could by tracing wires, reading resistor values, and measuring capacitances.  It is hard to measure capacitance in circuit, and only the input and output capacitors are reasonably reliable.


Reverse-engineered board schematic. The design is essentially the same as the examples in the data sheet (other than too small an inductor).

I spent a lot of time with my Analog Discovery 2, trying to plot voltage and current curves for different loads.  I ran into some difficulty, as my 1Ω power 10W resistor that I tried using for sensing had too much inductance, so I ended up using two 0.5-ohm ¼W resistors in parallel for my sense resistor. (For lower currents, I initially used just one resistor, but at high currents that would have gotten too hot.)

I tried also playing with non-resistive loads (putting an inductor in series with the resistor or a capacitor in parallel).  What I expected to see was that putting an inductor in series would reduce the current ripple, and that putting a capacitor in parallel would reduce the voltage ripple.  Putting a 100µH inductor in series with the load did indeed smooth out the current ripple as expected.

But capacitors had a weird effect. Here are some of the plots:

Putting a big low-ESR (aluminum polymer) capacitor in parallel with the load increased the voltage ripple instead of decreasing it!

Voltage ripple was fairly constant for moderate loads, but got extreme once the current requested got high.

The ±50mV voltage ripple had a frequency of about 930kHz, which was consistent with the 100kΩ resistor used on the FREQ input. At larger currents  (somewhere between 1.34A and 1.46A) the frequency dropped by a factor of 4 or 5, and the ripple went way up.

At first, I could not understand how capacitors could increase the ripple, nor could I make sense of the dV/dt slopes of the voltage.  Partly this came from misunderstanding the block diagram:

Block diagram, copied directly from the data sheet for the MP1584 (copyright Monolithic Power Systems Inc.).

I thought that the system was a simple PWM system, with the oscillator turning on the nFET between SW and Vin, and the feedback deciding when to turn it off.  When the nFET is on, the inductor (and load) current rises. When the inductor is off, the inductor continues to conduct, pulling SW down and eventually turning on the Schottky diode.

The set-reset latch (cross-coupled NAND gates) in the middle makes it look like a simple 2-state system: ON and OFF, but it turns out to be more complicated than that.  The oscillator does indeed turn the nFET on, but the feedback does not turn it fully off. Instead, the nFET oscillates between being on and being off, possibly based on the SW voltage.  The block diagram shows the gate voltage of the nFET as being referenced to SW, so once the nFET is off it should stay off, but I suspect that there are delays that result in the nFET turning back on as SW drops (at least if SW drops fast enough).

I tried looking at the input current to the regulator, which should spike up every time the nFET is turned on.  (Because I was using a 0.25Ω sense resistor on the input and the input capacitor seems to be 10µF, there is a 2.5µs RC time constant that averages out the input current, keeping it from appearing as large spikes.)

The spikes on the input current shows that the nFET turns on and off several times during the cycle, not just once when the oscillator requests it. The input current spikes correspond to places where the output voltage is rising.
Note: this plot averages 500 traces, to reduce the noise on the current measurements.

So the system is not a simple PWM switching between on and off, but switches between on and pulsing. The pulses seem to be around 7.4 MHz, much faster than the oscillator (about the 8th harmonic).

I think I have an explanation for the switching to lower frequencies for the ripple and getting larger ripples at low frequencies. The R+C circuit on the COMP pin is integrating a current proportional to the error to get an error control voltage.  That means that we have essentially a PI (proportional-integral) control loop, with R setting the coefficient for P and C setting the coefficient for I.  When we don’t have sufficient actuator values (that is, when we can’t raise the voltage fast enough with the FET on or lower if fast enough with the FET off), the integrator suffers from “integrator windup” (see my discussion in controlling temperature with just a heater and fan), accumulating lots of error that takes time to be erased.  Windup causes there to be massive overshoot.

We can fix the windup problem by either reducing the integrator coefficient (reducing the capacitor size on the COMP node, whose current size I’m uncertain of) or by using a larger inductor, so that the current changes less when the FET switches, and the time constant of the system is better matched to the integration time constant set by the RC value. [Update 2017-Sep-2: the reasoning here is wrong.  See Correcting reasoning on buck regulators.]

The data sheet makes it clear that the MP1584 is not designed to be used as an adjustable regulator—the R3 and C3 values for the compensation need to be adjusted based on the load resistance, the output capacitor, the output voltage, and the frequency.  They recommend choosing a switching frequency, then setting a crossover frequency to about 0.1 times that.  If we keep the 930kHz switching frequency, then f_c=93kHz.  They then recommend R_3=\frac{2\pi f_c C_2}{G_{EA} G_{CS}} \frac{V_{out}}{V_{FB}}, where C_2 is the output capacitance G_{EA}=60\mu A/V is the error amplifier transconductance, G_{CS}=9A/V is the current-sense amplifier transconductance, and V_{FB}=0.8V is the feedback voltage.  For a 10µF output capacitor and a 6V output, this would set R3=81kΩ, close to the 100kΩ chosen.  With a 470µF output capacitor, R3 would need to increase to around 390kΩ.

To choose C3, they recommend C_3 > \frac{4}{2\pi f_c R_3}, or C_3 > 68pF for R3=100kΩ, and I think that they chose 100pF (but I’m not certain).  With this method for picking R3 and C3, they are setting the RC time constant larger than 4 times the time constant for the crossover frequency, or larger than 40 times the time constant for the switching frequency.  The tradeoff between R3 and C3 is based on the output capacitance  (and output voltage and switching frequency), with larger output voltage, capacitance or switching frequency increasing R3.

I think that the values for R3 and C3 are reasonable on the board, but there is nothing on the data sheet about what to do when integrator windup happens—they recommend big enough inductors that I don’t think it is a problem for them, so I’m going to try replacing the inductor on the board with a good 10µH inductor, probably Abracon ASPI-0630LR-100M-T15, which looks like it is close enough in size to solder onto the same pads.  I’ll let people know in a couple of weeks whether this works.


2017 August 26

Review of cheap buck regulators

Filed under: Robotics,Uncategorized — gasstationwithoutpumps @ 14:15
Tags: , ,

I recently bought some very cheap buck regulators from Ali Express:

At only 44¢ each with claimed specs

Input voltage: 4.5V-28V
Output voltage: 0.8V-20V
Output Current: 3A (maximum)
Conversion efficiency: 96% (maximum)
Output ripple: <30mV
Switching Frequency: 1.4MHz (highest), typical 1MHz
Operating temperature: -45 to +85 degrees Celsius
Dimensions: 22mm * 17mm * 4mm

they seemed too good to pass up.  The data sheet for the MP 1584EN chip seemed to justify the claims, so I bought three of them to try out.

I’ve done a little testing with a 12V input and the output set to 6.08V, and they seem not to work as specified:
DC RMS voltage [V] DC RMS current [mA] Peak-to-peak ripple [mV] ripple freq [kHz]
6.091  0 15.09 6.29
6.098  1.9  69.1  34.0
6.084  16  70.1 65
6.077  194  75.8  930.4
6.072  376  104 929.1
6.072  568  122.8  929.7
6.163 1309 2266 168.1
6.084  2131  1576  230.3

The regulation to an average voltage is fine, but the ripple is enormous! Adding a capacitor (470µF aluminum polymer) helps at higher currents, but not much, and hurts at the 0.3–0.6A level:

DC RMS voltage [V] DC RMS current [mA] Peak-to-peak ripple [mV] ripple freq [kHz]
6.090  0  7 0.0396
6.090  1.9  28.2  35.5
6.090  15.8  18.4  3.6
6.077  194  75.5  930.3
6.078  375  310.3  465.2
6.083  568  630.6  465.8
6.091  1246  910  464.9
6.088  2112  1028  461.4
A 1µF ceramic (instead of a 470µF electrolytic) actually helps more at the higher currents, possibly because the electrolytic capacitor is too slow to respond (large equivalent series resistance and lead inductance).
DC RMS voltage [V] DC RMS current [mA] Peak-to-peak ripple [mV] ripple freq [kHz]
6.090  0  11.4 7.8
6.090 2.2  59  30.7
6.090  16.7  62  62
6.077  194  82  930.3
6.077  376  123  929.3
6.071  577  137  929.6
6.075  1297  189  928.0
6.088  2155  636  305.4

Still the regulator is way out of spec for ripple pretty much across the board.

The only explanation I’ve come up with for this way-out-of-spec behavior is that the manufacturers may have used a very cheap inductor which saturates at a much lower current than the 3A this regulator is supposed to provide.  A 150mA 10µH inductor costs about 3¢, while a 3.2A one costs about 17¢ (in 1000s)—on a 44¢ device, that’s a big difference in cost!  (In single-unit quantities, the price is more like 50¢ each for a beefy enough inductor.)

The inductor is not labeled, so determining what it is would require removing it from the board and soldering on some test leads.  That might be worth doing, especially if I could find a decent inductor of the same size (both physically and in terms of inductance) to replace it with.  If a 50¢ part fixes the boards, they might still be worthwhile, as adequately beefy DC-DC converters from reputable companies cost $10 or more, and designing and building my own board would cost a lot more than just replacing the inductor.

2017 August 23

Motor testing

Filed under: Data acquisition,Robotics — gasstationwithoutpumps @ 02:20
Tags: , ,

I bought some 6V motors with mounting brackets, wheels, and Hall-effect rotary encoders from Ali Express (, which arrived today, so I spent most of the day playing with them and trying to characterize them.

The first thing to do was to try to relate voltage, current, and speed.  I used the power supply in the Analog Discovery 2 to drive the motor through a resistor, monitoring both the voltage across the motor and the current through the resistor.  I used a Teensy LC board running PteroDAQ to monitor the frequency of the pulses from one of the Hall-effect sensor.  Initially I had tried looking at the pulses with the logic analyzer of the Analog Discovery 2, which gave me a fine short trace from which I could look at individual pulse widths and periods, but not get a long-term average frequency.

Varying the voltage on the motor gave different speeds, and the speed was linear with the voltage.  The current also went up with the voltage, but not linearly (it remained around 40mA even for very low voltages, and only went up to about 67mA at the highest voltages).

The standard simplified model for a motor is an “RLV” model: a resistor, an inductor, and a speed-dependent voltage source (referred to as the back-EMF).  V(s) = R I + L dI/dt + V_s s, where the speed is s, and the current is I. With a constant input voltage, the inductor is not really modelable, so I came up with an RV model:

The speed here is represented by the Hall-effect sensor, which gives 11 ticks per turn of the motor shaft. The back-emf is about 7.64 mV/Hz and the resistance is about 4.8Ω.

I needed about 2.5–3V to start the motor, but once it was running I could reduce the voltage to around 0.667V before the motor stopped (the lower speeds in the plot above were done by reducing the voltage with the motor running).

I tried measuring the impedance of the motor with the new impedance tool of Waveforms 2015. I got somewhat different results depending on the frequency used and the test voltage. For ±1V and low frequencies (under 300Hz), I got around 3.5–3.6mH+4.25Ω, but at higher frequencies the inductance dropped and the resistance increased: at 40kHz I had 1.946mH+438.5Ω. With a 5V signal I got 5.1mH+4.88Ω around 20Hz and down to 1.62mH+484Ω at 40kHz. The resistances at low frequencies are fairly consistent with the resistance I inferred from the back-EMF+IR model. So I’m reasonably comfortable in modeling the motor as having
V(s) = (7.64 mV/Hz) s + 4.8\Omega \,I + 4mH \,dI/dt.

I may have to tweak that inductance, though, as I’m not sure which frequency’s inductance is relevant.

I also recorded the turn-on transients of the motor. I tried first doing this by turning on the power supplies while the oscilloscope was waiting for a trigger, but the power supplies turn on quite slowly, so I added an nFET to the negative rail and controlled the gate with a pushbutton. The pushbutton connected the gate to a positive voltage and the gate had a large pulldown resistor to ground. The large pulldown resistor eventually turns the FET off when the button is released, but slowly enough that contact bounce does not result in turning the nFET on and off.

The voltage initially spikes up to the supply voltage, then the current increases through the inductor, until the resistive voltage divider controls the voltage. Then the motor starts moving and the back emf increases. The initial spike is very short (about 2ms), but spinning up the motor takes over 200ms.

You can see the enormous commutator signal in the voltage and the current. The current is directly controlled by the commutation—the voltage signal is only affected because of the IR drop across the 10Ω sense resistor I used for sensing the current.

We can use the initial turn-on spike to estimate the inductance, by looking at the exponential curve for the growth of the current:

The current is growing towards 412.5mA with a time constant of 311.76µs.

The inductance is just R times the time constant, where R is the series resistance (the 10Ω sense resistor and the 4.8Ω internal resistance—I’ll ignore the on-resistance of the MOSFET). L = 311.76 \mu s 14.8\Omega = 4.61 mH.

All the speed measurements here were in terms of how fast the Hall-effect sensor on the motor shaft was pulsing, but how fast is the output shaft of the gearbox turning? There are two questions: what is the ratio of sensor pulses to motor rotations, and what is the ratio of motor rotations to output shaft rotations?

The website for the motor claimed “Encoder motor end: 11 signals”, which I took to mean that there were 11 pulses per rotation.  I confirmed this by doing a Fourier transform of the commutation signal (the current) and of the pulse signal.  The fundamental of the pulse corresponded to the 11th harmonic of the current, so there were 11 pulses per turn of the motor shaft.

Determining the gear ratio (ratio of motor speed to output shaft speed) was more difficult.  I set up an optical interrupter to be blocked by a bit of electrical tape on the end of the output shaft once per revolution, and recorded the optical signal on every rising edge of the Hall-effect pulse using PteroDAQ.  By recording for a while, I could count the number of Hall-effect pulses for some integer number of shaft rotations.  Taking the pulses/output rotation and dividing by 11 gave me the motor-shaft rotations per output shaft rotation (the gear ratio I was seeking).  Getting a real number for this was fairly straightforward, but I wanted a rational number using products of small integers, corresponding to the gear teeth on the gears!

For one run, I had 856 shaft rotations with 200523 or 200524 pulses (depending whether I counted between rising edges or falling edges of the optical signal), giving me 234.255841121 to 234.257009346 pulses per rotation, or a gear ratio of 21.2959855565 to 21.2960917587.

I did a longer run with 4811 shaft rotations with 1126978 pulses or 1127000 pulses , giving me 234.250259821 to 234.254832675 pulses per rotation or a gear ratio of 21.2954781655 to 21.2958938795.

I converted the gear ratio to a continued fraction using my pocket calculator, getting


which expands to

21 + 1/3 = 21.3333333…

21 + 3/10 =21.3

21 + 8/27 = 21.29630…

21 + 37/125 = 21.296  = 2662/125 = 2 * 11^3 / 5^3   

The last ratio factors nicely, and looks feasible for a gear ratio.  To confirm my estimate, I carefully took apart one of the gearboxes and counted the teeth on the gears.  I got

  • motor shaft 12T
  • engages 22T linked to 10T
  • engages 22T linked to 10T
  • engages 22T linked to 10T
  • engages 24T on output shaft

This gearing does indeed give me the 2 (11/5)^3 gearing I calculated!

So my gear ratio is exactly 21.296 and I have exactly 234.256 pulses per rotation of the output shaft (with the quadrature coding from two Hall effect sensors, I get exactly 937.024 transitions per rotation).

With 6.0364V across the motor, I got 752.37Hz from the sensor, so the output shaft was rotating at 3.212Hz, or 192.7 rpm (somewhat slower than the claimed 210 rpm for 6V no load). The wheels that came with the motors have a circumference of 215mm, so the maximum speed would be 69cm/s, which is about 1.54 mph—not a real zippy machine, but more than fast enough for a small robot.

The tires are pretty squishy, though, and if I want to use the wheel turns to keep track of location, I’ll probably want wheels whose diameter doesn’t vary with the load—perhaps I could wrap the hubs with friction tape. The hub circumference is only 161mm. I could also laser-cut some wheels to get whatever diameter I want.

2017 August 15

Beacon detector SPI interface

Filed under: Robotics,Uncategorized — gasstationwithoutpumps @ 12:53
Tags: , , ,

In Beacon detector board, I introduced the hardware for the IR beacon detector, and in Digital tone detection with Goertzel’s algorithm, I discussed the algorithm used for detecting a 2kHz signal in a noisy background.  In this post I’ll talk about the software for interfacing the board to microcontrollers as if it were a standard peripheral device.

When I was designing the hardware, I had to choose between providing a UART interface, an SPI interface, or an I2C interface. At one point, I considered including all three, since I had just enough pins to do that and plenty of board space for connectors.

My son urged me to use a UART interface, since asynchronous communication is much easier work with than the two synchronous interfaces—there are no tight timing constraints. UART communications tends to be slow (115200 baud is a common top speed, resulting in a maximum of about 11.5–12.8kbytes/second transferred), and the two sides must agree on the baud rate to within 2.5%. But there are no latency constraints—you can respond to a request whenever you are finally ready—so there are no worries if you need to wait for a timer task to complete before communicating. The main downside of a UART interface (besides the usually low speed) is that it is a one-to-one interface. Two pins are needed for each UART a microcontroller uses, while the synchronous interfaces provide shared bus communication.

I knew that I could do a UART interface and for the small amounts of data I needed to communicate (10–75 bytes every 60th of a second, or 600–4500 bytes/s) it would be fast enough. But I wanted a challenge that would help me learn something new, so I decided to do a synchronous interface. Of the two choices supported by the Teensy LC hardware, SPI and I2C, the SPI interface looked the simpler to implement in software, as the timing seemed a little less challenging, and there was a FIFO that could be loaded with several bytes of information to transfer, reducing the timing demands. (In retrospect, I2C may have been easier—I’ve not tried it, though, so there may be some unexpected challenges.)

I created the board with only one I/O port (other than the USB port used for programming the board), the SPI0 4-wire interface using pins CS=D10=PTC4, MOSI=D11=PTC6, MISO=D12=PTC7, SCK=D13=PTC5.  I used a 6-pin right-angle header at the edge of the board, so that I would be able to use a ribbon connector to connect to another microcontroller. The order of the pins is the same as Digilent uses for their PMOD connector—an arbitrary choice, but there does not seem to be a commonly accepted standard for SPI connections.

The choice of pins was the first mistake I made in the SPI design—I should have used SPI1 instead of SPI0.  In reading the reference manual for the KL26 chip that is the basis for the Teensy LC, the SPI FIFO is only implemented for SPI1, and not for SPI0.  Also, the legal SPI clock speeds are different for the two interfaces:  SPI0 is clocked off the bus clock (default 24MHz on the Teensy LC) and SPI1 off the system clock (default 48MHz). The external clock SCK is allowed to go from 0Hz to ¼ the module clock, so 6MHz for SPI0 and 12MHz for SPI1.

The lack of a FIFO on SPI0 made the timing for loading the transmit buffer a little tricky.  The hardware has two registers for the transmit: the shift register used for serializing a byte and the transmit buffer that holds the next byte to transfer to the serial register.  If the transmit buffer is not loaded in time for the serial shifting, then the SPI interface will duplicate the previous byte, messing up communication.

The Teensyduino library contains SPI master software, but not SPI slave software.  I was wondering about the reason for that before I started my coding, but I quickly realized why—the timing for SPI is almost entirely under control of the master and the slave is constrained to respond at times specified by the master.  The most common SPI protocols for peripherals consist of the master sending a 1-byte (or longer) command to the slave and getting a response back in the next byte slot(s).  This gives the slave about half a clock period to interpret the command and prepare the response. With a 1MHz SCK, that gives the processor about 500ns to set up the response. That’s plenty of time for an all-hardware system, but is a very tight constraint for a software implementation.  In fact, given that the interrupt latency on the KL26 can be about 800ns, it is an impossible constraint—I don’t even know that I need to send a byte, much less figure out what it is, in the available time.  The more complicated I2C interface allows a slave to stretch out the clock when it can’t respond in time, but the SPI interface doesn’t allow the slave to change the clock rate.

So I couldn’t use the most common SPI interface protocol of command followed by immediate response. I had a few choices of workarounds for the latency problem:

  • Have a standardized packet of material that is sent independent of what the master does.  This seems to be the solution used by SPI slave libraries others have written for the Teensy boards (not part of the standard Teensyduino library).  It allows high throughput, especially if DMA is used to load the transmit information, but is not very flexible.  It is not a commonly used protocol on SPI peripherals.
  • Require the master to wait before asking for the response bytes.  This is very flexible and allows the SPI bus to run at maximum speed during transfers, but is not really in the spirit of a synchronous interface—the slave should respond at a standardized time, and the master should not have to know how long it will take the slave to be ready to send.
  • Send a dummy byte in the slot after the request so that I have a full byte time (8 SCK periods) instead of half a bit time to get the right information ready. A disadvantage is that the throughput is reduced—the dummy bytes take up bus time without communicating useful information. If the protocol calls for a 1-byte command and a 1-byte response, then each transfer would take 3 byte times.  (A 1-byte command and an n-byte response takes n+2 byte times.)

I ended up using a slight variant of the dummy-byte approach: I allow the master to send new commands before the first response comes back.  Dummy bytes are only added when there are no real bytes to send, so a series of n commands requesting 1-byte responses could be sent in a row, with the total time for the transfer taking n+2 byte times—the first two slots of which the slave is sending dummy bytes, and the next n are the requested data.

To make this protocol work, I had to ensure that the SPI interrupt priority is higher than any other interrupts in the program, in particular, higher than the PIT timer that I was using for the 15kHz sampling frequency.  This means that the SPI transmissions will introduce jitter into the ADC sampling—I’ve not yet determined how much of a problem this will be, but I suspect it won’t be much of a problem, since it will only affect one or two samples in the 250-sample filter block.  The default interrupt priority on the KL26 processor in the Teensy LC is for all interrupts to be at the highest priority, so I had to lower the PIT priority rather than raising the SPI priority.

The basic notion is that I keep the SPI transmit buffer always full.  When there is a transmit-buffer-empty interrupt, I load the buffer from a software FIFO I maintain, or with a dummy byte (0xff) if there is nothing in the FIFO.  The responses to a command are loaded into the FIFO.  As long as the SPI interrupt response (including interpreting the command and any FIFO loading or popping) takes less than the time of one byte, the protocol runs smoothly.  With commands that can send up to 4-byte responses, I was able to run SCK up 1.25MHz without losing synchronization.

My current, minimal command set for the beacon detector has the following commands:

  1. Freeze the information from filter so that all subsequent commands refer to the same set of data.  Return 1 on success, 0 on failure.  (The failure is only possible if the request is sent too soon after a reset of the beacon detector board.)
  2. Report which channel has the highest power (1-byte: 0xff if no beacon detected, otherwise 0..7)
  3. Report the estimated angle of the beacon in 0.1° units (2-bytes: 0..3599)
  4. Report the power in the max-power channel (4-bytes: unsigned int)

I could also report the power in specific channels and the power from an alternative (3kHz instead of 2kHz) filter for each channel, which would be another 64 bytes of information, but I’ve not implemented those commands yet.  The minimal set I currently have responds with 8 bytes of information, so takes 10 byte times for a burst of communication. With the highest clock rate I’ve gotten to work (SCK=1.25MHz), a full packet takes 64µs, which would interfere with only one or two samples of the 15kHz sampling.

I may play around with different command sets after I get another board programmed as a master to communicate with the beacon detector and determine what information I really need from the beacon detector.  One possibility is to use just a single 2-byte response that encodes everything but the power: that would allow a 4-byte-time packet (25.6 µs).

Setting up the SPI software ran into all the usual problems with setting up a peripheral on a Kinetis ARM processor—there are many registers that need to be set up correctly, and nothing works until they are all right:

  • Turn on the SPI module clock: SIM_SCGC4 |= SIM_SCGC4_SPI0
  • Set the SPI control registers SPI0_C1 and SPI0_C2 for 4-wire SPI with CPOL=1, CPHA=1, 8-bit mode, interrupt on receiving a byte or on transmit buffer empty.
  • Set up the isr to interpret the recieved bytes and keep the transmit buffer full.                                           
  • Configure the 4 pins used to be ALT 2 (SPI0) rather than the default GPIO.
  • Set the priorities using NVIC_SET_PRIORITY(IRQ_SPI0, 0) and NVIC_SET_PRIORITY(IRQ_PIT_CH1, 64).  The KL26 processors have only 4 interrupt priority levels that are multiples of 64.  Lower numbers are higher priority.
  • Enable the interrupts with NVIC_ENABLE_IRQ(IRQ_SPI0)

I debugged the SPI interface using the protocol and logic analyzer tools in the Analog Discovery 2.  I found the user documentation for these tools really awful (almost no information), but I managed to get things working by trial and error (except for the “sensor” script options for the SPI protocol tool—that always resulted in the spinning beachball and force-quitting Waveforms 2015).  I initially tested with the “Master” tab of the protocol tool, but I fairly quickly switched to using the “Custom” tool which allowed me to set up more complicated sequences of reads and writes, though eventually I simplified back to writes that could be done with the “Master” tab.

The “debug” mode of the protocol tool sets up the logic analyzer to see the signals, but then doesn’t provide the decoding of the protocol in the protocol tool—one has to go to the logic analyzer to set up the triggering, switch to the protocol tool to send the stimulus, then switch back to the logic analyzer to see the results.  It is possible to get the protocol tool and the logic analyzer tool in different windows (double-click on the tab for the tool you want in a new window), but my screen is too small for showing both windows in sufficient resolution at once.

To see when the interrupt service routine for the SPI was active I added CORE_PIN1_PORTSET = CORE_PIN1_BITMASK to the beginning of the isr and CORE_PIN1_PORTCLEAR = CORE_PIN1_BITMASK, and used some wirewrap wire to get the pin 1 signal out to the logic analyzer. I’d not added test points for the unused pins, but because the Teensy board is socketed with female headers, it was easy to wrap a wire around the pin before pushing the board into the female headers, and use a loose header pin to connect the other end of the wire to DIO6 of the logic analyzer.

Here is a result of a test of sending the 4 commands in a row in an 11-byte frame, to make sure that the dummy bytes occur in the right places (in the first 2 and last slots of the 11-byte frame):

The MISO line shows the correct responses from the beacon detector: 0xff, 0xff, 1 (freeze ok), 0 (channel 0), 0x00e1=225=22.5°, power=0x08436020=138633248.

As it turns out, the end of the isr for the 4-byte response comes 0.4µs later than it should if there had not been any other bytes already in the queue. Indeed, if I start with the “4” command, things just barely work, because the isr routine starts a little sooner. The 6.8µs delay to the end of the isr routine suggests to me that the maximum safe rate for SCK is only about 1.15MHz, not 1.25MHz.  I’ll have to do a lot of testing with many data packets, to see what rate is really safe without intermittent errors.  That will have to wait until I’ve written a program to act as the master (unless I can figure out why the “sensor” script keeps crashing Waveforms 2015).

Next Page »

Create a free website or blog at

%d bloggers like this: