Jeff Epler's blog

Codeword BISON ZENITH

(M)(L)

intel-fab42

Connect the dots:

Internal Intel memos from as early as 2008 confirm a skunkworks plan to develop metamaterials—a "superlens"—rather than pursue techniques like EUV for post-14nm process nodes. The "superlens" was supposed to be able to focus normal UV light onto sub-wavelength regions, impossible for traditional optics and even according to the predictions of quantum physics.

FOIA requests show hundreds of chartered flights yearly from the NSA's Utah Data Center to the Chandler Municipal Airport, just 3 miles from Intel's Fab 42 just outside Phoenix Arizona, starting in 2012 and continuing until April 2018.

The uncanny resemblance of Chandler's Cottonwood and Sun Lakes golf course developments to class D and F warding glyphs; and the unusually strict anti-occult and anti-religious symbol rules in the HOA covenants. (This would have been for the safety of the subdivision's occupants; at such short range even as innocuous a religious symbol as a "marshmallow peep" would burst into flame within the area of the glyph itself)

Results from ABJAD SURVEY show that in near-habitable parallels, the most frequent parameter variation that prohibits the survival of an earth biosphere is in the parameter 'c', the speed of light. Variations as small as 3% prevent pollinators from locating flowers, but even variations of 27% are short-term survivable by adult humans, given proper personal protection.

The unexplained hour of localized daytime darkness in Chandler AZ on 4/18/18; initially reported as a "terror attack", there were no direct casualties (just road accidents). The official NTSB report states that the crashed Cessna 680 on arrival from Salt Lake City had no one on board.

Our conjecture:

When the Black Chamber shows up with credentials thst say "NSA" and promises you access to an out of this world process for creating integrated circuits, you need to take that phrase literally. But of course in the first two decades of the century, there was no awareness of this in the general public. And if you were on the inside, you would authorize such activities as a matter of course.

The "superlens" technology is better understood as a pair of back to back gates, leading to a region of the multiverse with the a 'c' value about 70% below nominal. This would allow a UV process that supported the 17nm node in our physics to scale down to the 5nm mode, allowing Intel to maintain its worldwide process advantage for a decade or more.

Black Chamber produced the superlenses at the Utah Data Center and hand delivered them to Intel staff who were unaware of just what they were handling. The gates were presumably designed with a half life of around a week, based on the frequency of flights. This plan went fine, until something happened on the 4/18 flight. Did containment of the gates fail during the flight, or was it a part of a defection plan or a convert operation by one of our adversaries?

In any case, Intel never did ship a post-14nm part from the Chandler fabrication facility.

Editor's note: Strictly speaking, 'c' is not a parameter, since it is not one of the fundamental dimensionless constants. Technically, I should say 'ɑ'. But since the effect we're interested in pertains to the speed of light, it is clearer to express things in these terms. Remember, in atomic units 'ɑ = 1/c'.

[permalink]

Codeword BISON MERIDIAN

Many later historians claim that it was the reports of atypical neuropathy in staff at GlobalFoundries labs that tipped off the Black Chamber to the dangers of extreme nanoscale lithography. The earliest reports, of course, said nothing about the US Occult Service's involvement; instead there were just bland mutterings about "business opportunities" and "emerging high-growth markets" to explain the (now decade-long) shuttering of an entire wing of the Santa Cara facility.

The second cover story was floated when the first leaks related BISON MERIDIAN were posted to the SCP Foundation wiki. In this version, not directly contradicted by anything in the public record, semiconductor chips manufactured with EUV Lithography produced produced silicon clumps of a particular size that allowed them to escape environmental filters and cross the blood-brain barrier into facility staff, leading to the reported symptoms.

It was actually the animal sacrifices, reported by a Black Chamber asset on the custodial staff, that first tipped off the authorities. In typical Chamber fashion, everyone who might have been involved in the sacrifices was rounded up and "debriefed" (and so what if the subjects never again have full sensation on their tongues and the bottoms of their feet?).

According to an unredacted BISON MERIDIAN folio obtained by the author, the Black Chamber's found that sub-10nm lithography techniques had inadvertently created a summoning grid for what one subverted researcher worshipped as "Otvor Bog" (literally "God of the Aperture", though possibly also a play on the English-language phrase "God of the Gaps"). Unlike most extradimensional incursions, which are information-theoretic in nature, the semiconductor wafer actually extrudes the body of Otvor Bog, albeit just a 16x16mm section of it at a rate of around 4ml/day.

This author cannot help but connect this evidence to the codewords BISON NADIR and BISON ZENITH which have also appeared in redacted reports; to the continued delays in Intel's next-generation lithography process; and to TSMC's apparent success in this region, together with rumors of the "black safes" throughout that facility. The author has been unable to confirm reports that the "shuttered" GF buildings have continued to draw power from the electric grid at a rate that far exceeds the requirements of a few energy lights and environmental monitoring devices.

One final tidbit from BISON MERIDIAN: As the primary atomic constituents of an Otvor Bog type incursion are oxygen, hydrogen, silicon, and nitrogen, (and no carbon) SIDE EYE (basilisk sidearm) is not an effective countermeasure.

[permalink]

GPSDO: An attempt that is too simple

Two DACs to give greater dynamic range

read more…

keyestudio gps shield as frequency counter

(M)(L)

The two GPS receivers on my window sill

I chose this model because it has a ublox GPS module and a header with signals marked "GP" and "EX". EX should be external interrupt, and it opens the possibility of a simple GPS-disciplined frequency counter.

It comes with a small antenna, short cable. One of those godawful laptop style connectors, and no provision for directly soldering a better one. Sigh.

read more…

Fun with frequency

10MHz OCXO (top), 10MHz GPS-referenced (bottom)

• A new 4-channel scope
• A GPS-referenced tunable frequency generator
• A "PLJ-8LED-C" frequency counter from ebay
• An "AD9850 DDS freqency synthesizer breakout" from ebay
• A 10MHz OCXO from ebay years ago and miraculously rediscovered midway down a junk pile this weekend

Nothing earth shattering or super fancy, but it is still pretty amazing to be able to heat or cool the AD9850's (non-compensated) XO and see the digital frequency meter change. And it was gratifying to find that the OCXO can be tuned quite easily to 10,000,000MHz.

The PLJ frequency counter is adequate to its task. Supposedly it has a VC-TCXO, and while it has just a single turn adjustment for frequency, I was able to get it to consistently read 10,000,000MHz from OCXO and from GPS; the next day, it had drifted down to 9,999,999. Still, that's down in the .1ppm and is probably to be expexcted.

I found that when tuning the OCXO, it was much more useful to use the scope to visualize the changing relative phases of the two signals, than to use this particular frequency meter which needs a 1s gate time to measure a 10MHz signal at a precision of 1Hz, and can't do anything more precise than that.

To tune the OCXO, I set the GPS-referenced RF generator to 10MHz and hooked both up to the scope. With a time base of 100ns and a persistence of 10s, it's not only easy to fine tune the circuit, but a hand-wave estimate of the error by looking at the persisted signal. If it's 1 div wide, then the relative error between the two frequencies is 100ns/10s = 10ppb = 10 milliHz @ 10MHz.

The scope has a 1kHz signal for probe compensation and it also includes the signal generator option. To my surprise, the frequency error of the probe compensation was MUCH smaller than the frequency error of the signal generator!

[permalink]

All integers 0 through 1,000,000 from short, digitless dc programs

I consider the 23 characters " ~^-/*+|ABCDdEFIinOorvz", but prune all prefixes which are invalid due to stack underflow. 23¹² is around 2.2×10¹⁶ or 2⁵⁴, but best guess my various programs have considered only around 5×10¹² or 2⁴² due to this pruning. Still, the process (including iteratively developing the search program) has taken several months!

What's next? I guess there's always the "fours puzzle", dc edition.

      4 4n
     10 In
      0 zn
     44 44n
      2 4vn
      1 4zn
      3 Ivn
    444 444n
      6 44vn
     40 4I*n
...

Files currently attached to this page:

[permalink]

Code size for bit reversing algorithms

Code space is always at a premium, so I investigated several code fragments for bit reversal to find out which was smallest on arm and xtensa. These code fragments are gathered from the internet. The loop is the smallest alternative on both architectures, but the 16-element look up table is not much bigger (on arm, the difference is bigger on xtensa) and is probably faster.

arm-none-eabi-gcc-7.2.1 -Os -mthumb

   text    data     bss     dec     hex filename
     40       0       0      40      28 bitrev_loop.o
     44       0       0      44      2c bitrev_lut16.o
     44       0       0      44      2c bitrev_shifts1.o
     44       0       0      44      2c bitrev_twiddle1.o

xtensa-lx106-elf-gcc-4.8.5 -Os

   text    data     bss     dec     hex filename
     40       0       0      40      28 bitrev_loop.o
     53       0       0      53      35 bitrev_lut16.o
     57       0       0      57      39 bitrev_shifts1.o
     52       0       0      52      34 bitrev_twiddle1.o

Files currently attached to this page:

[permalink]

Fuzz-testing CircuitPython

(M)(L)

afl-graphs

I recommend that you use a throwaway virtual machine for this, because at one point afl-fuzz learned how to create files in the filesystem! that was a big surprise, waking up to a directory full of filenames like "tesppppppppppppppppppppppppppppptfile"!

First, make sure you can build circuitpython's unix port. The steps are, approximately,

1. Clone circuitpython
2. git submodule update --init --recursive
3. make -C ports/unix -j5 deplibs
4. make -C ports/unix -j5

Note that the executable is ports/unix/micropython even when you have cloned circuitpython.

Next, get afl from http://lcamtuf.coredump.cx/afl/. If you can, follow the instructions in llvm_mode/README.llvm to get afl-clang-fast. Now, clean and rebuild:

1. make -C ports/unix clean
2. make -C ports/unix CC=/path/to/afl-clang-fast -j5 deplibs
3. make -C ports/unix CC=/path/to/afl-clang-fast -j5

Prepare the testcases directory for afl-fuzz. I used a number of tests from tests/basic:

1. mkdir testcases
2. cp tests/basics/*.py testcases

And start the fuzzer:

1. /path/to/afl-fuzz -i testcases -o findings -- ports/unix/circuitpython

If you have any good findings, drop by the adafruit circuitpython discord and let us know about them! Even better if you fix them.

[permalink]

Watch Repairs

Finding all numbers produced by short, digitless 'GNU dc' programs

Four years of Prius (2013) fuel efficiency

poc: Python OCE Composer

occmodel as Python alternative to openscad

MP Select Mini: Heated Bed Repair

My internet usage would fit on six 33.6kb/s modems on average

Monoprice Select 3D Printer Review (part 4)