Project Logs

Collapse

• Do You Need AnaQuad?

  Eric Hertz • 12/07/2021 at 19:30 • 11 comments

  Yet another draft not submitted... It's now May, this was written in December......

  ....

  AnaQuad's design is for some very specific use-cases... I should put more effort into highlighting that. 

  Not long ago, using a [digital!] quadrature encoder at all was such a CPU-intensive process that pretty much the only reasonable way to do-so in any high-speed/high-resolution application (CNC) required a chip dedicated to counting quadrature... (e.g. HCTL-2000-series). This was pretty much the /only/ fast-enough solution to assure no steps went missed.

  Today, even a lowly 8bit RISC microcontroller can be put to that task without hiccuping... BUT, doing-so with /any/ processor running code, it's *extremely* important that the quadrature-decoding code be executed fast-enough and often-enough that no steps can possibly be missed. 

  This is where things get tricky. It's not only a matter of making sure the quadrature-handling code is fast and called often, but also a matter of making *certain* any other code running on the same processor can never delay it too much, e.g. during a rare case like an interrupt occurring at exactly the wrong time. 

  Thus, one obvious technique is to put the quadrature-handler *in* a high-priority edge-triggered interrupt... this also has the benefit of sparing CPU cycles by not executing the quadrature-handler when there is no motion. 

  But that too brings about its own set of problems... E.G. now the opposite is true, when it moves fast, quadrature decoding uses a lot more CPU cycles than when it moves slow. 

  So, now, imagine your CPU is trying to calculate a motion-control feedback loop... Slow motions work great! But as the speed increases, suddenly the feedback loop is being starved of CPU time, just when it needs more of it!

  ...

  Thus, to try to get a more realistic idea of what such a system's limits are (from the start of such a project, rather than building the project and later testing its limits), I've actually stepped *back* in the de-facto progression of such development. E.G. Removing the quadrature code from its [seemingly ideal] interrupt, and instead lockstepping it with the motion-control code. In this way, neither can starve the other, because both are *always* running at the maximum rate possible *for both.*

  Note in my vids, my display shows a "loop counter" that, if I do things right, to my intent, should remain constant regardless of motion or lack thereof. This tells me *exactly* the limits of the system, regardless of whether I'm pushing those limits, or just turned it on for the first time with nothing attached. A loop-count of 40,000/sec tells me the motor cannot exceed 40,000 quadrature-steps/sec. And, in fact, the motion-control code, lockstepped with the quadrature code, guarantees it can't unless something is wrong (shorted motor driver-chip, etc.). Then, I can be certain not to surpass those limits in my usage of the system. 

  Think of 40,000 steps/sec, here, like the "Absolute Maximum" specification in a chip's datasheet. Request this value and it will likely work just fine... certainly won't break... OTOH, who knows what'll happen? TESTING that limit is *very* implementation/situation-specific... 999 times out of 1000 it may work without a hitch.

  Say the motor requires 70% PWM duty-cycle to move your CNC axis at 40,000 quardrature steps/sec. Hey, works great! No limits being pushed. Well within expectations! Let's use it!

  OK, now say the carriage encounters an aluminum shaving on the leadscrew. The PWM increases to 75% to maintain the requested 40,000 steps/sec, due to the extra drag caused by that shaving sliding along with the carriage.

  OK, now that shaving falls off the leadscrew.

  What happens?

  Well, the system detects it doesn't require as much power to maintain 40,000steps/sec, so decreases the PWM back down to 70%... right?

  NO.

  Because when that shaving falls off at 75% PWM, the carriage speed will accelerate....

  Read more »

• Inspired experiments in visualization

  Eric Hertz • 12/07/2021 at 08:41 • 0 comments

  This crossover-detection scheme is really hard to explain in words... I've tried countless times but what I really need is a great graphic.

  Here are some attempts:

  (And DAG NAB wouldn'tchaknow, switching tabs cleared all my work, leaving me with only a handful of screenshots)

  Above is an example of what can result from using arctan when the measurements are off by +-10% (5%?)... This may seem like extremes that are unlikely to be encountered, but bear with me, anyhow.

  The overall error at any of the measured positions is, frankly, not even near the step-size of anaQuad. So, at first glance it still seems like arctan is a great choice for higher resolution. And, indeed, depending on your application, it may be.

  But consider this: With enough (only 5%?) measurement-error, noise, miscalibration, low battery, etc., arctan can report positions *decreasing* when in fact the motions are increasing. That can be a pretty significant problem if those position measurement/calculations are being fed into a feedback control loop.

  Also, as described before, the area near arctan's discontinuities is of great concern, now multiplied. Notice how now the arctan lines overlap, jumping back and forth between roughly -90 and +90 degrees. Such a case would require special attention to avoid potential disaster in a motion-control situation.

  Here's another example:

  The stair-steps are anaQuad's output. Again, it has hysteresis...

  Thus It's rather difficult to trigger the misdetection of a reversal where there was none.

  The example above is at an extreme 20% error on each measurement, which one might hope never to run into...

  On the other hand, we tend to push things beyond their specifications, in these parts... maybe completely unintentionally. And that's easy to do in analog.

  For example, in one of my older videos, my analog optical encoder circuit had a strange effect where the outputs' amplitudes decreased somewhat dramatically with motor speed (WHAT?!). Maybe something to do with slew-rates? Rise/fall times? Internal capacitance?

  But, say the amplitude, was merely 10% in error... no big deal, eh? But, consider this: The encoder is powered by a single supply voltage... its output is not centered at 0V. And the DC offset /also/ varied somewhat dramatically. So now our measurements with respect to ground, as the ADC reads them, are 20% in error! And to add to it, that was the error on only one of the two WAY-off channels.

  Here's the extreme, where anaQuad may start failing:

  40% error on both channels(!!!) causes weird cases where the hysteresis oscillates back and forth between two measured positions. As shown by the gaps and dashes in the stairsteps.

  TBH, I'd never really contemplated what would happen in such a case... and I've never looked at it like this, graphically...

  And it's past friggin midnight, brain-mush is allowed, no?

  I *think* the hysteresis still applies, so e.g. the yellow line would *not* occur, falling through the crack to the next step, but then coming right back to the previous through the same crack... hmmm...

  This is a very weird and enlightening visualization for me! And it can be animated, too.

  ...and I've been extremely busy with other things like destroying my progress on #Vintage Z80 palmtop compy hackery (TI-86)  which could really help with a much more pressing project than even that, so what am I doing /here?!/

  Yeah, guess I'm pretty proud of this one.

• AnaQuad was Peer Reviewed!

  Eric Hertz • 12/06/2021 at 19:41 • 2 comments

  The other day I stumbled on a couple videos from by @Jesse Schoch , wherein he actually implemented anaQuad in a system, gave a pretty thorough overview/discussion, and even expanded on it both in software and by using it in a unique way!

  My work was Peer Reviewed!
  

  like... the highest honor for a scientist... and somehow I didn't find out, except by accident, two years later. Believe me, Jesse, I'd've definitely been in contact, had I known.

  ON TO THE VIDS:

  Jesse doesn't have much of a profile here at HaD, instead he has a wealth of YouTube videos of such projects and concepts.

  Back in 2019 (I almost wrote 1999, jeeze I'm old), Jesse dedicated some of his time to implementing anaQuad, and made these vids.

  (Apologies; I'd planned to be more thorough in analyzing the vids, themselves, but these days I'm on flakeynet most of the time... I cross my fingers every time I click "Save". Heh!)

  Part 1:

  Jesse discusses a use-case I'd never considered, a pair of analog hall-effect sensors used to detect the 2mm-spaced alternating poles of a magnetic strip (refrigerator magnet) passing by. AnaQuad is used here to determine the linear motion/position.

  I'm not sure I understand his sensor, it has an X and a Z axis, and somehow their readings are at or near 90deg out of phase. However it works, it's a great observation, and a perfect use for anaQuad!

  It reminds me of a linear version of 5.25in floppy spindle motors, which have a similar magnet with many alternating poles wrapped around the edge of the (for lack of a better word) flywheel. The hall-effect sensors, there, are three-phase, so offset by 60deg each. I did once modify anaQuad[120] for two of those sensors. Though, the poles were so far apart that resolution was quite low despite the 10+ inches of magnet spinning by.

  One observation about this setup is that, if I understand hall-sensors, the waveform output by the sensors would vary in amplitude (and DC-offset?) if these magnets aren't perfectly-aligned with the sensor throughout the entirety of their motion. E.G. if the sensor's path relative to the linear strip isn't /perfectly/ parallel. Also, who knows about the magnetic poles themselves? Surely a fridge-magnet isn't made to tight tolerances. Here, I'm not so much talking about the spacing, that's probably pretty consistent due to the machine that made it. Instead I'm talking about the /strength/ of each pole being consistent across the entire strip. E.G. I would imagine some poles may weaken with various outside factors; being exposed to other magnets on the fridge, etc. Or, also, plausibly, if this is used on an axis of a metal-cutting CNC, the measured flux may vary slightly based on the amount of nearby metal stock.

  THIS IS A PERFECT USE FOR anaQuad.

  The whole point of its crossover-detection is to reduce the effects of such things on the position-sensing. Imagine one weak pole surrounded by many normal ones, for which the system was calibrated. There, the sine-wave would have a reduced amplitude. And, the surrounding poles might even cause it to have a slight offset from "zero". I won't go into all the details, they've been harped-on in other logs, sufficed to say anaQuad is by-design highly tolerant to such variances.

  ...

  In this first vid, Jesse touches on the concept of merging anaQuad with "sin-cos" postioning. This, honestly, is something I never really considered, as I'd kinda figured the two to be somewhat competitors. Heh!

  Part 2:

  In the second video, Jesse goes into a bit more detail about how anaQuad works, then shows how to combine it with trigonometry to gain even higher positional-resolution.

  The use of trigonometry is something I was /actively/ trying to avoid when developing anaQuad. So, it's difficult for me not to go into all the details of why, and instead see the benefits. I'll try to be open-minded ;)

  First-off, having seen his graphical visuals, then inspired to run my own calculations, I'm actually quite surprised...

  Read more »

• PRML

  Eric Hertz • 09/23/2018 at 03:09 • 1 comment

  hmmm....

  http://www.pcguide.com/ref/hdd/geom/dataPRML-c.html
  

  So, hard disks now use ADCs and DSPs to detect ones and zeros...

  This looks like a job for ANAQUAD!

  Is it too much to ask that two heads on opposite sides of the platter (or maybe two on the same?) stay perfectly-aligned over time and temperatures? 'Cause a rough estimate using anaQuad would easily double, plausibly even quadruple, the capacity despite using twice the physical space...

  Thanks @Starhawk for sending me down that path, looking up ZIP drives' encoding-schemes!

• motor as encoder

  Eric Hertz • 09/14/2018 at 03:41 • 1 comment

  Yeah!

  #Motor as Encoder 
  

  Use a BLDC motor as an encoder. Almost *Exactly* as I'd imagined. Combine this with anaQuad, and yer all set!

  Note that anaQuad *also* works with two sources that are 120 degrees out of phase, so only two windings of the three in a typical BLDC should be necessary. Also, his technique could probably also be applied to stepper motors.

  I dunno how i never seem to come up with this simple concept, myself...

  "how can I measure capacitance? Drive with an AC signal, measure phase/magnitude..."

  Had to learn this one by example... Simple capacitive touch switches charge the cap, then measure the time it takes to discharge...

  Friggin' simple method to apply multiple pushbuttons on a single pin is exactly the same, tie them to different resistor values, charge a cap, measure the discharge time, simple ADC. Bam. I even have a well-developed project based on that (anaButtons, as I recall).

  No phase/mag necessary. So, why, then, couldn't I come up with the same for inductors? Duh.

  Nice goin' @besenyeim!

  I'mma linking this one here so's I can come back to it when the time is right-er.

• QPSK

  Eric Hertz • 11/21/2017 at 21:13 • 0 comments

  stumbled upon QPSK (quadrature phase-shift keying) which apparently is the/a method used to transmit data in WiFi...

  This looks, actually, quite similar to my earlier rambling thoughts on using anaQuad as a data-transmission method.

  Some key (hah) points: 

  QPSK, since it's tied to RF signals, relies on a phase-shift that's maintained for *numerous* cycles (the carrier wave), whereas anaQuad uses two separate wires, and no carrier frequency, so phase-shifts can be easily detected several times *within* a cycle.

  While this may make the two seem quite different, I think both techniques are quite similar in concept, owing most of their differences to their medium.

  Also QPSK allows for *two* bits to be transmitted simultaneously... one for each phase in the quadrature signal. Whereas my earlier thoughts for anaQuad only transmits one.

  (QPSK, Wikipedia)

  There's good reason. QPSK can allow for signal changes with discrete jumps, each bit-encoding is independent of the previous. The same could be done with anaQuad, plausibly allowing up to 16 or more values (4 bits) to be encoded in each ... thing. (Phase-shift, maybe. Or key?)

  My earlier ramblings on anaQuad used as data-transmission explicitly removed the ability for sudden jumps in the signal. Thus, one bit is encoded into each "key" dependent on whether there's a positive phase-change or negative. (Plausibly trinary, considering no-change). Thus, each bit-value's representation (as viewed as a waveform) is entirely dependent on the previous.

  Now, I'm not certain I read this correctly, but I think I saw mention that QPSK, or some derivation, is sometimes used similarly.

  My reasoning: transmission-lines and slew rates. Sudden changes have slew rates to take into account... transmission lines can *smooth* a sharp edge by the time it reaches a receiver. Also, the receiver itself has slew-rates, the transistors don't switch *immediately*... and... anaQuad pushes those switching-speeds by working with smaller/slower changes (and linear regions).

  But... if that somewhat arbitrary limitation was removed, and if the technique was transmitted over a carrier-wave, instead of two wires (and a separate clock? Probably only necessary in the trinary case)... and if it were cut down to only four phases (actually, it seems there are QPSK-derivatives that have more), it would seem the ramblings on using anaQuad for data transmission are... darn-near exactly the same as QPSK, of which I had no prior knowledge.

  Yay!

  A particularly interesting-to-me learning from QPSK is how the quadrature signals are combined into one... at any instant, except during a phase-change, the signal appears to be nothing but the carrier frequency. So detecting the phase change must require the receiver to have a duplicate of the unshifted carrier-wave running somewhere to compare to... Not dissimilar to how an LVDS receiver uses a PLL to recreate the bit-clock, or how a floppy drive synchronizes an internal clock to clock-pulses on the diskette which are *not* alongside *every* bit. 

  Not sure how/if to use that with anaQuad... in the two-wire, single-bit, method, clocking is inherent with the bit-phase-transitions. OTOH, it requires two wires.

  Mathematically, knowing the two "wire" phases are always quadrature, is it possible to use superposition to combine them on a single wire, still extract the two signals to gain the benefits of "crossover-detection" (noise/source-calibration immunity, mainly) and have inherent-clocking? Sounds like a tall order. But... hmmm....

• more graphing...

  Eric Hertz • 04/14/2017 at 10:36 • 0 comments

  UPDATE: Ramblings on LVMDS feasibility/usefulness... why do I do this? See the bottom.

  ---------
  

  A little more on LVMDS (anaQuad serial-transmission)
  

  explained below...

  -----------------
  
  

  Thought I'd experiment with different graphing-methods... my old go-to online-grapher seems to be down, so here's another:

  The idea was to show only the crossovers, for a half-period of the quadrature-signal... one half sine-wave, which is the passing of one "slot" in the encoder-disk over the photo-sensor (the other half-sine-wave would be passing of the light-blocking material, which I can't figure out the name for, at the moment... maybe "tooth"?). The other half-sine-wave would be basically the same.

  So we have two piecewise-equations:

  y1(t) = sin(t)       * (t<pi/8)   * (t>-1)  
        + sin(t)       * (t>pi/8)   * (t<3*pi/8)
        + sin(t+pi/2)  * (t>3*pi/8) * (t<5*pi/8)
        + sin(t)       * (t>5*pi/8) * (t<7*pi/8)
  
  y2(t) = -sin(t)      * (t<pi/8)   * (t>-1)
        + sin(t+pi/2)  * (t>pi/8)   * (t<3*pi/8)
        + -sin(t+pi/2) * (t>3*pi/8) * (t<5*pi/8)
        + -sin(t+pi/2) * (t>5*pi/8) * (t<7*pi/8)

  As it stands, I think it's a bit too funky to visualize, the other graphs were more intuitive for me.

  But the ultimate goal, here, (which I'd forgotten until I started writing this, having developed these graphs before the ordeal at home weeks ago) is to make it easier to visualize an encoder (or LVMDS) where the speed/direction changes...

  E.G. For an encoder-disk, we'd be talking about say a motor slowing to a stop at a specific position. With a poorly-tuned algorithm, it might oscillate around that point due to overshoot. Then, graphing that using the method shown here would allow for a more ideal simulation where speed/position isn't affected by other factors such as the motor's windings or friction. That'd help for explanation-purposes.

  E.G.2. For LVMDS, we'd be talking about transmission of data-bits, wherein a "1" would be represented by a clockwise-rotation of one "step" and a "0" would be represented by a counter-clockwise-rotation of a "step."

  The latter-case would be much easier to visualize with this sort of graphing technique... E.G. show the transmission of a data-byte in this anaQuad method. So, maybe I'll get there.

  As it stands, this graphing program only allows for two plots... so the color-coordination doesn't really make sense... it doesn't correspond to anything in particular, you have to look at the piecewise functions to see what's happening.

  Also, this only demonstrates the simplest implementation of anaQuad, which only doubles the resolution of a typical digital-output optical-encoder.

  (If this were compared to two LVDS signals, this method doubles the number of bits that can be transferred within one "eye" or one bit-clock, which would be the blue line crossing over the horizontal axis at 0 and PI).
  

  So, maybe I need to write a program to do the graphing... or at least generate the necessary equations.

  We'll see.

  #Iterative Motion also could benefit from a GUI, so maybe it makes sense to try to refresh myself on OpenGL...

  Oh, I have a relatively simple idea for LVMDS... brb.

  So, here we can see the binary pattern 11011000 transmitted via anaQuad aka LVMDS... not quite as visually-intuitive as I'd prefer, but a start, anyhow.

  Also, doesn't show the hysteresis method explained in a previous log, wherein a switch in direction/bit-value would maybe take *two* crossovers to detect, rather than one, just to assure stability, should the electrical-values end-up *near* a crossover, rather than halfway-between.

  So, you might be able to see, if there were *two* parallel LVDS signals, their "eyes" would align on the half-sine-wave roughly-outlined in blue. Two data-bits could be transferred simultaneously between 0 and 3.14, one bit on each "signal."

  With LVMDS, using two electrically-similar signals as those in LVDS, when those two signals are in quadrature, *four* data-bits can be transferred in the same time, without increasing slew-rates, etc. Something to ponder, anyhow...

  ---------

  So, some pondering, maybe... between...

  Read more »

• LVMDS revisited...

  Eric Hertz • 04/01/2017 at 14:01 • 3 comments

  It's been some time... I don't recall what LVMDS stands for anymore...

  LVDS = Low-Voltage Differential-Signalling...

  And the M...? Multi?

  Some theorizing was presented in previous logs (long ago), here's my attempt at trying to remind myself what I was thinking.

  -------------
  

  Anyways, here's anaQuad revisited:

  There are two sine-waves, with a 90-degree phase-shift between 'em. (the two blue lines). These are, e.g. the outputs of the two Quadrature signals of an optical-encoder.

  anaQuad, again, increases the resolution of the encoders by looking at crossovers between various multiples of the two input signals. By *inverting* the two input-signals (red), we can detect 8 positions (8 cross-overs) per full-cycle (the blue dots). (This resolution is twice as high as could be detected with digital quadrature signals).

  By multiplying the input-signals by ~2, we can double the resolution to 16 positions (the green dots). The resolution can be further-increased by adding more [and more complicated] multiples of the two input-signals, but let's ignore all these for a second and just look at the red and blue waves.

  The red and blue waveforms give 8 positions per full cycle. That's 4 positions per half-cycle, using two quadrature signals.

  That's for increasing the resolution of a quadrature [optical] encoder with analog output.

  -----------------
  

  Imagine, now, if these crossovers represented data-bits in a serial-data-stream...
  

  -------------------------
  

  First some background...
  

  Here's an "eye diagram" for a regular ol' serial-data-stream (e.g. RS-232)

  (http://electronicdesign.com)
  

  The waveforms forming the "eye" are numerous bits of a data-stream overlayed atop each other.

  (http://electronicdesign.com)
  

  When the bit in the center is high, and the two surrounding it are low (#7, above), you'll see a full-sine-wave, starting low on the left, rising to the top of the "eye," and ending low on the right. (If the baud-rate is *really slow* compared to the rise/fall times, it'll look more like a square-wave... as one might expect of a digital signal. For a high-speed serial data-stream, the rise-times and fall-times are almost as long as the high-level and low-level bits, making the waveform more of a sine-wave.)

  Similarly, when the bit in the center is low, and the two surrounding it are high (#5), you'll see the same half-sine-wave flipped upside-down.

  When three bits are high (#4), you get the top line straight across. Three low, straight across the bottom (#2)... And several other combinations (two bits high, one bit low (#8), and so-forth).

  So the eye-diagram shows many bit-patterns overlapping. One might say the center of the "eye" is sampled by the input of the receiving shift-register.

  -----------------------

  Now, for a *differential* serial data signal, we'd see a similar diagram; for every high-bit on one wire, the other wire sends a simultaneous low bit, and vice-versa. It's symmetrical across the horizontal line bisecting the eye (wee!).

  Generally, the receiver might be e.g. a comparator connected to those two opposite-valued signals. When one signal is higher than the other, the output of the comparator is 1, when the other signal is higher, the output is 0.

  The bit-value is, essentially, determined at the *time of crossover* between the two input-signals. (Though, technically, most LVDS receivers *sample* the bit-value in the middle of the "eye").

  --------------

  Now let's go back to anaQuad...

  anaQuad works by looking at the *crossover* of two signals, much like differential-signals (LVDS). But, does-so between not only the input-signal (blue) and its inverse (red), but also a second input-signal and its inverse (the second blue and red pair, respectively)... (as well as multiples thereof (green), which I'm ignoring for now).

  By transmitting two signals, in quadrature (the two blue waveforms), at the same frequency as, say, an LVDS signal, we can determine *four* different crossover values (the blue dots) in a single "eye" (half-sine-wave) (ignoring, again, the...

  Read more »

• The Idea...

  Eric Hertz • 03/30/2017 at 08:48 • 0 comments

  The idea of anaQuad is to use an analog-quadrature source (such as the encoder disks used in an old "ball-mouse") to achieve significantly higher resolution than could be achieved by treating that quadrature-signal digitally. While being relatively immune to analog noise, calibration-error, etc.

  It does-so, reliably, by *not* looking at analog *thresholds*, but instead looking at analog *crossovers*. This is well-explained in these pages.
  

  There are several potential sources... Some quadrature-encoders output an analog signal rather than digital (again, e.g. looking at the output of the photo-transistors in a computer's ball-mouse). Some other sources include the hall-effect sensors used in BLDC motors (these are usually 120 degrees out of phase, rather than 90, as in quadrature, but anaQuad120 can handle that).

  To *use* this system... Currently it's a software-only approach:

  Two analog-to-digital converters are necessary for each encoder.

  (Though, theoretically this could be implemented in hardware with a few comparators and op-amps, or maybe even voltage-dividers!)

  anaQuad (the software) implements a non-blocking function-call to test the current state of your ADCs and determine the current state (and therefore update the "position")...

  In all, it executes only a handful of instructions to detect a change in position, or lack thereof. So as long as it's called often-enough (faster than changes can occur), it puts little strain on your system. The same could be accomplished with a non-blocking digital quadrature-encoder routine in only a few fewer instruction-cycles. This could be called in a timer interrupt or from your main loop (if everything therein is non-blocking, and it loops fast enough).

  Interestingly, anaQuad appears capable of "resynchronizing" if a few "steps" go undetected. So, e.g. if your main loop is slowed for some reason during one cycle, and a few anaQuad "steps" are missed, as long as the next few main-loops are faster, the system won't lose any steps! (Again, probably smarter to use a timer interrupt if you're not certain).

• Home-made anaQuad discs!

  Eric Hertz • 04/30/2016 at 09:29 • 5 comments

  @Logan linked an interesting and easy-to-build encoder-disk method in a comment over at @Norbert Heinz's #Self replicating CNC for 194 (or more) countries project (which has a bunch of ideas for various positioning systems)...

  Check out this guy: https://botscene.net/2012/10/18/make-a-low-cost-absolute-encoder/

  I'll let the image speak for itself:

  So, the current implementation of anaQuad(4x) would give 16 positions with that disk, per revolution. But, that could easily be bumped to 32 via software, and there's no reason the disk has to have only two "poles".

  I think something like this would be easier to build than the ol' "slotted" style disks, since slots would require a tiny (or masked) sensing-area, etc.
  

View all 19 project logs