Advertisements

Archive for May, 2017

AD9850 DDS Module: Temperature Sensitivity

While tinkering with the SPI code for the AD9850 DDS module, I wrote down the ambient temperature and the frequency tweak required to zero-beat the 10 MHz output with the GPS-locked oscillator. A quick-n-dirty plot summarizing two days of randomly timed observations ensued:

AD9850 DDS Module - Frequency vs Temperature

AD9850 DDS Module – Frequency vs Temperature

The frequency offset comes from the tweak required to zero-beat the output by adjusting the initial oscillator error: a positive tweak produces a smaller count-per-hertz coefficient and reduces the output frequency. As a result, the thermal coefficient sign is backwards, because increasing temperature raises the oscillator frequency and reduces the necessary tweak. I think so, anyway; you know how these things can go wrong. More automation and reliable data would be a nice touch.

Foam sheets formed a block around the DDS module, isolating it from stray air currents and reducing the clock oscillator’s sensitivity:

AD9850 DDS module - foam insulation

AD9850 DDS module – foam insulation

I used the ambient temperature, because the thermocouple inside the foam (not shown in the picture) really wasn’t making good contact with the board, the readings didn’t make consistent sense, and, given a (nearly) constant power dissipation, the (average) oscillator temperature inside the foam should track ambient temperature with a constant offset. I think so, anyway.

The coefficient works out to 0.02 ppm/°C. Of course, the initial frequency offset is something like -400 Hz = 3 ppm, so we’re not dealing with lab-grade instrumentation here.

Advertisements

,

9 Comments

AD9850 DDS Module: Hardware Assisted SPI and Fixed-point Frequency Stepping

Having conjured fixed-point arithmetic into working, the next step is to squirt data to the AD9850 DDS chip. Given that using the Arduino’s hardware-assisted SPI doesn’t require much in the way of software, the wiring looks like this:

Nano to DDS schematic

Nano to DDS schematic

Not much to it, is there? For reference, it looks a lot like you’d expect:

AD9850 DDS Module - swapped GND D7 pins

AD9850 DDS Module – swapped GND D7 pins

There’s no point in building an asynchronous interface with SPI interrupts and callbacks and all that rot, because squirting one byte at 1 Mb/s (a reasonable speed for hand wiring; the AD9850 can accept bits at 140+ MHz) doesn’t take all that long and it’s easier to have the low-level code stall until the hardware finishes:

#define PIN_HEARTBEAT    9          // added LED

#define PIN_RESET_DDS    7          // Reset DDS module
#define PIN_LATCH_DDS    8          // Latch serial data into DDS

#define PIN_SCK        13          // SPI clock (also Arduino LED!)
#define PIN_MISO      12          // SPI data input
#define PIN_MOSI      11          // SPI data output
#define PIN_SS        10          // SPI slave select - MUST BE OUTPUT = HIGH

void EnableSPI(void) {
  digitalWrite(PIN_SS,HIGH);        // set SPI into Master mode
  SPCR |= 1 << SPE;
}

void DisableSPI(void) {
  SPCR &= ~(1 << SPE);
}

void WaitSPIF(void) {
  while (! (SPSR & (1 << SPIF))) {
    TogglePin(PIN_HEARTBEAT);
    TogglePin(PIN_HEARTBEAT);
    continue;
  }
}

byte SendRecSPI(byte Dbyte) {           // send one byte, get another in exchange
  SPDR = Dbyte;
  WaitSPIF();
  return SPDR;                          // SPIF will be cleared
}

With that in hand, turning on the SPI hardware and waking up the AD9850 looks like this:

void EnableDDS(void) {

  digitalWrite(PIN_LATCH_DDS,LOW);          // ensure proper startup

  digitalWrite(PIN_RESET_DDS,HIGH);         // minimum reset pulse 40 ns, not a problem
  digitalWrite(PIN_RESET_DDS,LOW);
  delayMicroseconds(1);                     // max latency 100 ns, not a problem

  DisableSPI();                             // allow manual control of outputs
  digitalWrite(PIN_SCK,LOW);                // ensure clean SCK pulse
  PulsePin(PIN_SCK);                        //  ... to latch hardwired config bits
  PulsePin(PIN_LATCH_DDS);                  // load hardwired config bits = begin serial mode

  EnableSPI();                              // turn on hardware SPI controls
  SendRecSPI(0x00);                         // shift in serial config bits
  PulsePin(PIN_LATCH_DDS);                  // load serial config bits
}

Given 32 bits of delta phase data and knowing the DDS output phase angle is always zero, you just drop five bytes into a hole in the floor labeled “SPI” and away they go:

void WriteDDS(uint32_t DeltaPhase) {

  SendRecSPI((byte)DeltaPhase);             // low-order byte first
  SendRecSPI((byte)(DeltaPhase >> 8));
  SendRecSPI((byte)(DeltaPhase >> 16));
  SendRecSPI((byte)(DeltaPhase >> 24));

  SendRecSPI(0x00);                         // 5 MSBs = phase = 0, 3 LSBs must be zero

  PulsePin(PIN_LATCH_DDS);                  // write data to DDS
}

In order to have something to watch, the loop() increments the output frequency in steps of 0.1 Hz between 10.0 MHz ± 3 Hz, as set by the obvious global variables:

      PrintFixedPtRounded(Buffer,ScanFreq,1);

      TestCount.fx_64 = MultiplyFixedPt(ScanFreq,CtPerHz);
      printf("%12s -> %9ld\n",Buffer,TestCount.fx_32.high);

      WriteDDS(TestCount.fx_32.high);

      ScanFreq.fx_64 += ScanStep.fx_64;

      if (ScanFreq.fx_64 > (ScanTo.fx_64 + ScanStep.fx_64 / 2)) {
        ScanFreq = ScanFrom;
        Serial.println("Scan restart");
      }

Which produces output like this:

DDS SPI exercise
Ed Nisley - KE4ZNU - May 2017

Inputs: 124999656 = 125000000-344
Osc freq: 124999656.000000000
Hz/Ct: 0.029103750
Ct/Hz: 34.359832926
0.1 Hz Ct: 3.435983287
Test frequency:  10000000.0000
Delta phase: 343598329

Scan limits
 from:   9999997.0
   at:  10000000.0
   to:  10000003.0

Sleeping for a while ...

Startup done!

Begin scanning

  10000000.0 -> 343598329
  10000000.1 -> 343598332
  10000000.2 -> 343598336
  10000000.3 -> 343598339
  10000000.4 -> 343598343
  10000000.5 -> 343598346
  10000000.6 -> 343598349
  10000000.7 -> 343598353
  10000000.8 -> 343598356
  10000000.9 -> 343598360
  10000001.0 -> 343598363
  10000001.1 -> 343598367
  10000001.2 -> 343598370
  10000001.3 -> 343598373
<<< snippage >>>

The real excitement happens while watching the DDS output crawl across the scope screen in relation to the 10 MHz signal from the Z8301 GPS-locked reference:

DDS GPS - 10 MHz -48 Hz offset - zero beat

DDS GPS – 10 MHz -48 Hz offset – zero beat

The DDS sine in the upper trace is zero-beat against the GPS reference in the lower trace. There’s no hardware interlock, but they’re dead stationary during whatever DDS output step produces exactly 10.0000000 MHz. The temperature coefficient seems to be around 2.4 Hz/°C, so the merest whiff of air changes the frequency by more than 0.1 Hz.

It’s kinda like watching paint dry or a 3D printer at work, but it’s my paint: I like it a lot!

The Arduino source code as a GitHub Gist:

,

3 Comments

Bathroom Door Retainer

The weather got warm enough to open the windows before pollen season started, which led to the front bathroom door slamming closed in the middle of the night when a gusty rainstorm blew through town. After far too many years, I decided this was an annoyance up with which I need no longer put.

A few minutes with OpenSCAD and Slic3r produces the shape:

Bathroom Door Retainer - Slic3r

Bathroom Door Retainer – Slic3r

It’s basically an extrusion of a 2D shape with a rectangular recess for the door chewed out.

An hour later, it’s in full effect:

Bathroom Door Retainer - installed

Bathroom Door Retainer – installed

The model now sports a little ball to secure the retainer against the towel bar:

Bathroom Door Retainer - bump

Bathroom Door Retainer – bump

Maybe someday I’ll reprint it.

That was easy …

The cast-iron pig sometimes standing guard as a doorstop in the relatively narrow doorway poses a bit of a foot hazard, so he moves into a closet during the off season. He can now remain there, snug and comfy, until a need for ballast arises.

The OpenSCAD source code as a GitHub Gist:

,

8 Comments

Road Conditions: Rt 376 Brush North of Maloney

NYS DOT ground the asphalt surface and repaved Rt 376, dramatically improving the southern route to the rail trail along Maloney Drive.

Alas, the Japanese Knotweed continues to flourish:

This slideshow requires JavaScript.

I sent a note to their email contact and got the usual autoresponder message, but may have a side channel through the Dutchess County Planning Department to their Bicycle Coordinator. We shall see.

1 Comment

Beware the Hissing Goose!

Rolling into Vassar Farms, we encountered a Canadian Canada Goose (*) family:

Geese at Vassar Farm Pond 2017-05-21

Geese at Vassar Farm Pond 2017-05-21

The gander pulled straight up and hissed as we rolled by at what we thought was a respectful distance:

Geese at Vassar Farm Pond 2017-05-21 - detail

Geese at Vassar Farm Pond 2017-05-21 – detail

Their little fuzzballs retreated in good order under the fence toward the pond; they don’t need much survival training.

Word has it a goose family (perhaps this one) built their nest near a path around the ponds and defend their turf with sufficient resolve to deter even singletrack bikers.

I occasionally see snakes along the way, but none that hiss:

Black Snake on Rail Trail - 2017-04-28

Black Snake on Rail Trail – 2017-04-28

We approach rail-trail curves with a bit more caution than some folks; I’m at about the spot where that rider began losing control and didn’t quite wipe us out.

Update: They’re “Canada Geese“, with (AFAICT) a legal distinction between Canadian tourists and resident Yanks during the hunting season. Thanks to David for the reminder!

12 Comments

Arduino vs. Significant Figures: Useful 64-bit Fixed Point

Devoting eight bytes to every fixed point number may be excessive, but having nine significant figures apiece for the integer and fraction parts pushes the frequency calculations well beyond the limits of the DDS hardware, without involving any floating point library routines. This chunk of code performs a few more calculations using the format laid out earlier and explores a few idioms that may come in handy later.

Rounding the numbers to a specific number of decimal places gets rid of the repeating-digit problem that turns 0.10 into 0.099999:

uint64_t RoundFixedPt(union ll_u TheNumber,unsigned Decimals) {
union ll_u Rnd;

  Rnd.fx_64 = (One.fx_64 / 2) / (pow(10LL,Decimals));
  TheNumber.fx_64 = TheNumber.fx_64 + Rnd.fx_64;
  return TheNumber.fx_64;
}

That pretty well trashes the digits beyond the rounded place, so you shouldn’t display any more of them:

void PrintFixedPtRounded(char *pBuffer,union ll_u FixedPt,unsigned Decimals) {
char *pDecPt;

  FixedPt.fx_64 = RoundFixedPt(FixedPt,Decimals);

  PrintIntegerLL(pBuffer,FixedPt);  // do the integer part

  pBuffer += strlen(pBuffer);       // aim pointer beyond integer

  pDecPt = pBuffer;                 // save the point location
  *pBuffer++ = '.';                 // drop in the decimal point, tick pointer

  PrintFractionLL(pBuffer,FixedPt);

  if (Decimals == 0)
    *pDecPt = 0;                    // 0 places means discard the decimal point
  else
    *(pDecPt + Decimals + 1) = 0;   // truncate string to leave . and Decimals chars
}

Which definitely makes the numbers look prettier:

  Tenth.fx_64 = One.fx_64 / 10;             // Likewise, 0.1
  PrintFixedPt(Buffer,Tenth);
  printf("\n0.1: %s\n",Buffer);
  PrintFixedPtRounded(Buffer,Tenth,9);                    // show rounded value
  printf("0.1 to 9 dec: %s\n",Buffer);

  TestFreq.fx_64 = RoundFixedPt(Tenth,3);                 // show full string after rounding
  PrintFixedPt(Buffer,TestFreq);
  printf("0.1 to 3 dec: %s (full string)\n",Buffer);

  PrintFixedPtRounded(Buffer,Tenth,3);                    // show truncated string with rounded value
  printf("0.1 to 3 dec: %s (truncated string)\n",Buffer);

0.1: 0.099999999
0.1 to 9 dec: 0.100000000
0.1 to 3 dec: 0.100499999 (full string)
0.1 to 3 dec: 0.100 (truncated string)

  CtPerHz.fx_64 = -1;                       // Set up 2^32 - 1, which is close enough
  CtPerHz.fx_64 /= 125 * MEGA;              // divide by nominal oscillator
  PrintFixedPt(Buffer,CtPerHz);
  printf("\nCt/Hz = %s\n",Buffer);

  printf("Rounding: \n");
  for (int d = 9; d >= 0; d--) {
    PrintFixedPtRounded(Buffer,CtPerHz,d);
    printf("     %d: %s\n",d,Buffer);
  }

Ct/Hz = 34.359738367
Rounding:
     9: 34.359738368
     8: 34.35973837
     7: 34.3597384
     6: 34.359738
     5: 34.35974
     4: 34.3597
     3: 34.360
     2: 34.36
     1: 34.4
     0: 34

Multiplying two scaled 64-bit fixed-point numbers should produce a 128-bit result. For all the values we (well, I) care about, the product will fit into a 64-bit result, because the integer parts will always multiply out to less than 232 and we don’t care about more than 32 bits of fraction. This function multiplies two fixed point numbers of the form a.b × c.d by adding up the partial products thusly: ac + bd + ad + bc. The product of the integers ac won’t overflow 32 bits, the cross products ad and bc will always be slightly less than their integer factors, and the fractional product bd will always be less than 1.0.

Soooo, just multiply ’em out as 64-bit integers, shift the products around to align the appropriate parts, and add up the pieces:


uint64_t MultiplyFixedPt(union ll_u Mcand, union ll_u Mplier) {
union ll_u Result;

  Result.fx_64  = ((uint64_t)Mcand.fx_32.high * (uint64_t)Mplier.fx_32.high) << 32; // integer parts (clear fract) 
  Result.fx_64 += ((uint64_t)Mcand.fx_32.low * (uint64_t)Mplier.fx_32.low) >> 32;   // fraction parts (always < 1)
  Result.fx_64 += (uint64_t)Mcand.fx_32.high * (uint64_t)Mplier.fx_32.low;          // cross products
  Result.fx_64 += (uint64_t)Mcand.fx_32.low * (uint64_t)Mplier.fx_32.high;

  return Result.fx_64;
}

This may be a useful way to set magic numbers with a few decimal places, although it does require keeping the decimal point in mind:

  TestFreq.fx_64 = (599999LL * One.fx_64) / 10;           // set 59999.9 kHz differently
  PrintFixedPt(Buffer,TestFreq);
  printf("\nTest frequency: %s\n",Buffer);
  PrintFixedPtRounded(Buffer,TestFreq,1);
  printf("         round: %s\n",Buffer);

Test frequency: 59999.899999999
         round: 59999.9

Contrary to what I thought, computing the CtPerHz coefficient doesn’t require pre-dividing both 232 and the oscillator by 2, thus preventing the former from overflowing a 32 bit integer. All you do is knock the numerator down by one little itty bitty count you’ll never notice:

  CtPerHz.fx_64 = -1;                       // Set up 2^32 - 1, which is close enough
  CtPerHz.fx_64 /= 125 * MEGA;              // divide by nominal oscillator
  PrintFixedPt(Buffer,CtPerHz);
  printf("\nCt/Hz = %s\n",Buffer);

Ct/Hz = 34.359738367

That’s also the largest possible fixed-point number, because unsigned:

  TempFX.fx_64 = -1;
  PrintFixedPt(Buffer,TempFX);
  printf("Max fixed point: %s\n",Buffer);

Max fixed point: 4294967295.999999999

With nine.nine significant figures in the mix, tweaking the 125 MHz oscillator to within 2 Hz will work:

Oscillator tune: CtPerHz
 Oscillator: 125000000.00
 -10 -> 34.359741116
  -9 -> 34.359741116
  -8 -> 34.359740566
  -7 -> 34.359740566
  -6 -> 34.359740017
  -5 -> 34.359740017
  -4 -> 34.359739467
  -3 -> 34.359739467
  -2 -> 34.359738917
  -1 -> 34.359738917
  +0 -> 34.359738367
  +1 -> 34.359738367
  +2 -> 34.359737818
  +3 -> 34.359737818
  +4 -> 34.359737268
  +5 -> 34.359737268
  +6 -> 34.359736718
  +7 -> 34.359736718
  +8 -> 34.359736168
  +9 -> 34.359736168
 +10 -> 34.359735619

So, all in all, this looks good. The vast number of strings in the test program bulk it up beyond reason, but in actual practice I think the code will be smaller than the equivalent floating point version, with more significant figures. Speed isn’t an issue either way, because the delays waiting for the crystal tester to settle down at each frequency step should be larger than any possible computation.

The results were all verified with my trusty HP 50g and HP-15C calculators, both of which wipe the floor with any other way of handling mixed binary / hex / decimal arithmetic. If you do bit-wise calculations, even on an irregular basis, get yourself a SwissMicro DM16L; you can thank me later.

The Arduino source code as a GitHub Gist:

, ,

14 Comments

Sharing the Lane on Burnett Blvd. at Rt 55

When we get to the end of Overocker Road, we occupy the entire left-and-straight lane, because we’re turning left onto Burnett Blvd and there’s no room for another vehicle beside us:

Burnett at Rt 55 - Right pass - 2017-05-23 - 1

Burnett at Rt 55 – Right pass – 2017-05-23 – 1

I’m towing a trailer of groceries.

On Burnett Blvd, we take the left side of the right lane (marked for left-and-right turns), because we’re turning left onto Rt 55, don’t want to get right-hooked by right-on-red traffic, and will be on the right side of the right lane of Rt 55 when we’re through the turn.

Without turn signals, it’s not clear whether the car following us from Overocker will turn left or right, but the driver is snuggling up next to Mary:

Burnett at Rt 55 - Right pass - 2017-05-23 - 2

Burnett at Rt 55 – Right pass – 2017-05-23 – 2

The driver’s window is sliding downward. Fortunately, we started moving before any comments were made. Perhaps he was going tell us we’re riding cool bikes?

Ah-ha! The driver is turning left and intending to pass me on the right while we’re in the intersection:

Burnett at Rt 55 - Right pass - 2017-05-23 - 3

Burnett at Rt 55 – Right pass – 2017-05-23 – 3

Helmet mirror FTW!

I’m moving rightward across the turning lane to end up on the right side of the Rt 55 lane, while not riding across the steel manhole cover at the car’s front wheel:

Burnett at Rt 55 - Right pass - 2017-05-23 - 4

Burnett at Rt 55 – Right pass – 2017-05-23 – 4

Mary doesn’t accelerate nearly as hard as I do; those pictures are one second apart.

I’m un-leaning from the turn into Rt 55, with the trailer still on my left and the driver accelerating toward me:

Burnett at Rt 55 - Right pass - 2017-05-23 - 5

Burnett at Rt 55 – Right pass – 2017-05-23 – 5

A close pass, but not too bad:

Burnett at Rt 55 - Right pass - 2017-05-23 - 6

Burnett at Rt 55 – Right pass – 2017-05-23 – 6

Most of the time, our rides aren’t this interesting, but I have plenty of examples showing how NYS DOT’s road designs ignore cyclists. The Burnett intersection signals still give us four seconds to clear the intersection.

Leave a comment