Archive for category Software
FM DDS: Floating Point Timing
Posted by Ed in Electronics Workbench, Software on 2018-04-23
Inserting a few simple floating point operations between the SPI transfers provides a quick-n-dirty look at the timings:
Math timing – double ops
The corresponding code runs in the ADC end-of-conversion handler:
void adc0_isr(void) {
digitalWriteFast(ANALOG_PIN,HIGH);
AnalogSample = adc->readSingle(); // fetch just-finished sample
SPI.beginTransaction(SPISettings(8000000, MSBFIRST, SPI_MODE0));
digitalWriteFast(DDS_FQUD_PIN, LOW);
SPI.transfer(DDSBuffer.Phase); // interleave with FM calculations
FlipPin(GLITCH_PIN);
TestFreq += DDSStepFreq;
FlipPin(GLITCH_PIN);
SPI.transfer(DDSBuffer.Bits31_24);
TestFreq -= DDSStepFreq;
SPI.transfer(DDSBuffer.Bits23_16);
TestFreq *= DDSStepFreq;
SPI.transfer(DDSBuffer.Bits15_8);
FlipPin(GLITCH_PIN);
TestFreq /= DDSStepFreq;
FlipPin(GLITCH_PIN);
SPI.transfer(DDSBuffer.Bits7_0);
SPI.endTransaction(); // do not raise FQ_UD until next timer tick!
digitalWriteFast(ANALOG_PIN,LOW);
}
The FlipPin() function twiddling the output bit takes a surprising amount of time, as shown by the first two gaps in the blocks of SPI clocks (D4). Some cursor fiddling on a zoomed scale says 300 ns = 50-ish cycles for each call. In round numbers, actual code doing useful work will take longer than that.
Double precision floating add / subtract / multiply seem to take about 600 ns. That’s entirely survivable if you don’t get carried away.
Double precision division, on the other paw, eats up 3 μs = 3000 ns, so it’s not something you want to casually plunk into an interrupt handler required to finish before the next audio sample arrives in 20 μs.
Overall, the CPU utilization seems way too high for comfort, mostly due to the SPI transfers, even without any computation. I must study the SPI-by-DMA examples to see if it’s a win.
Frequency Modulated DDS: SPI Mock 1
Posted by Ed in Amateur Radio, Electronics Workbench, Software on 2018-04-20
The general idea is to frequency modulate the sine wave coming from a DDS, thereby generating a signal suitable for upconverting in amateur repeaters now tied to unobtainable crystals. The crystals run from 4-ish to 20-ish MHz, with frequency multiplication from 3 to 36 producing RF outputs from 30-ish MHz through 900-ish MHz; more details as I work through the choices.
The demo code runs on a bare Teensy 3.6 as a dipstick test for the overall timing and functionality:
FM DDS – Teensy 3.6 SPI demo
The fugliest thing you’ve seen in a while, eh?
An overview of the results:
Analog 4 kHz @ 40 kHz – SPI demo overview
The pulses in D1 (orange digital) mark timer ticks at a 40 kHz pace, grossly oversampling the 4 kHz audio bandwidth in the hope of trivializing the antialiasing filters. The timer tick raises the DDS latch pin (D6, top trace) to change the DDS frequency, fires off another ADC conversion, and (for now) copies the previous ADC value to the DAC output:
void timer_callback(void) {
digitalWriteFast(TIMER_PIN,HIGH);
digitalWriteFast(DDS_FQUD_PIN,HIGH); // latch previously shifted bits
adc->startSingleRead(AUDIO_PIN, ADC_0); // start ADC conversion
analogWriteDAC0(AnalogSample); // show previous audio sample
digitalWriteFast(TIMER_PIN,LOW);
}
The purple analog trace is the input sine wave at 4 kHz. The yellow analog stairstep comes from the DAC, with no hint of a reconstruction filter knocking off the sharp edges.
The X1 cursor (bold vertical dots) marks the start of the ADC read. I hope triggering it from the timer tick eliminates most of the jitter.
The Y1 cursor (upper dotted line, intersecting X1 just left of the purple curve) shows the ADC sample apparently happens just slightly after the conversion. The analog scales may be slightly off, so I wouldn’t leap to any conclusions.
The pulses in D2 mark the ADC end-of-conversion interrupts:
void adc0_isr(void) {
digitalWriteFast(ANALOG_PIN,HIGH);
AnalogSample = adc->readSingle(); // fetch just-finished sample
SPI.beginTransaction(SPISettings(8000000, MSBFIRST, SPI_MODE0));
digitalWriteFast(DDS_FQUD_PIN, LOW);
SPI.transfer(DDSBuffer.Phase); // interleave with FM calculations
SPI.transfer(DDSBuffer.Bits31_24);
SPI.transfer(DDSBuffer.Bits23_16);
SPI.transfer(DDSBuffer.Bits15_8);
SPI.transfer(DDSBuffer.Bits7_0);
SPI.endTransaction(); // do not raise FQ_UD until next timer tick!
digitalWriteFast(ANALOG_PIN,LOW);
}
The real FM code will multiply the ADC reading by the amplitude-to-frequency-deviation factor, add it to the nominal “crystal” frequency, convert the sum to the DDS delta-phase register value, then send it to the DDS through the SPI port. For now, I just send five constant bytes to get an idea of the minimum timing with the SPI clock ticking along at 8 MHz.
The tidy blurs in D4 show the SPI clock, with the corresponding data in D5.
D6 (top trace) shows the DDS FQ_UD (pronounced “frequency update”) signal dropping just before the SPI data transfer begins. Basically, FQ_UD is the DDS Latch Clock: low during the delta-phase value transfer, with the low-to-high transition latching all 40 control + data bits into the DDS to trigger the new frequency.
A closer look at the sample and transfer:
Analog 4 kHz @ 40 kHz – SPI demo detail
For reference, the digital players from bottom to top:
- D0 – unused here, shows pulses marking main loop
- D1 – 40 kHz timer ticks = ADC start conversion
- D2 – ADC end of conversion,”FM calculation”, send DDS data
- D3 – unused here, shows error conditions
- D4 – SPI clock = rising edge active
- D5 – SPI MOSI data to DDS = MSB first
- D6 – SPI CS = FQ_UD = DDS latch
Remember, the yellow analog stairstepped trace is just a comfort signal showing the ADC actually samples the intended input.
The ARM CPU has floating-point hardware, but I suspect fixed-point arithmetic will once again win out over double-precision multiplies & divides.
Dropping the sampling to 20 kHz would likely work just as well and double the time available for calculations. At least now I can measure what’s going on.
All in all, it looks feasible.
And, yes, the scope is a shiny new Siglent SDS2304X with the MSO logic-analyzer option. It has some grievous UX warts & omissions suggesting an architectural botch job, but it’s mostly Good Enough for what I need. More later.
The TeensyDuino source code as a GitHub Gist:
Teensy 3.6 Double Precision Floats
Posted by Ed in Electronics Workbench, Software on 2018-04-19
Having spent a bit of effort wringing enough precision from an Arduino to make the 60 kHz quartz resonator tester, this came as a relief:
DDS frequency: 180000000.0000000 Hz
epsilon: 0.0000001 Hz
step: 0.0419095 Hz
Center frequency: 146520000.0000000 Hz
146520000.0000001 Hz
146520000.0000002 Hz
146520000.0000003 Hz
146520000.0000004 Hz
146520000.0000004 Hz
146520000.0000005 Hz
146520000.0000006 Hz
146520000.0000007 Hz
146520000.0000008 Hz
146520000.0000009 Hz
146520000.0000010 Hz
... snippage ...
146520000.0000099 Hz
146520000.0000100 Hz
146520000.0419195 Hz
146520000.0838290 Hz
146520000.1257386 Hz
146520000.1676481 Hz
146520000.2095576 Hz
146520000.2514671 Hz
146520000.2933766 Hz
146520000.3352861 Hz
146520000.3771957 Hz
146520000.4191052 Hz
146520000.4610147 Hz
146520000.5029242 Hz
146520000.5448337 Hz
146520000.5867432 Hz
146520000.6286528 Hz
146520000.6705623 Hz
146520000.7124718 Hz
146520000.7543813 Hz
146520000.7962908 Hz
146520000.8382003 Hz
146520000.8801098 Hz
146520000.9220194 Hz
146520000.9639289 Hz
146520001.0058384 Hz
146520001.0477479 Hz
146520001.0896574 Hz
146520001.1315669 Hz
146520001.1734765 Hz
Which comes from a PJRC Teensy 3.6 running this code:
double DDSFreq, EpsilonFreq, DDSStepFreq;
double CenterFreq, TestFreq;
... in setup() ...
DDSFreq = 180.0e6;
EpsilonFreq = 1.0e-7;
DDSStepFreq = DDSFreq / (1LL << 32);
Serial.printf("DDS frequency: %18.7f Hz\n",DDSFreq);
Serial.printf(" epsilon: %18.7f Hz\n",EpsilonFreq);
Serial.printf(" step: %18.7f Hz\n\n",DDSStepFreq);
CenterFreq = 146520000.0;
TestFreq = CenterFreq;
Serial.printf("Center frequency: %18.7f Hz\n",CenterFreq);
... in loop() ...
if (TestFreq < (CenterFreq + 100*EpsilonFreq))
TestFreq += EpsilonFreq;
else
TestFreq += DDSStepFreq;
Serial.printf(" %18.7f Hz\n",TestFreq);
The IEEE-754 spec says a double floating-point variable carries about 15.9 decimal digits, which agrees with the 9 integer + 7 fraction digits. The highlight lowlight (gray bar) in the first figure shows the slight stumble where adding 1e-7 changes the sum, but not quite enough to affect the displayed fraction.
In round numbers, an increment of 1e-5 would work just fine:
146520000.0000100 Hz 146520000.0000200 Hz 146520000.0000300 Hz 146520000.0000401 Hz 146520000.0000501 Hz 146520000.0000601 Hz 146520000.0000701 Hz 146520000.0000801 Hz 146520000.0000901 Hz 146520000.0001001 Hz 146520000.0001101 Hz 146520000.0001202 Hz 146520000.0001302 Hz 146520000.0001402 Hz 146520000.0001502 Hz 146520000.0001602 Hz 146520000.0001702 Hz 146520000.0001802 Hz 146520000.0001903 Hz 146520000.0002003 Hz 146520000.0002103 Hz 146520000.0002203 Hz 146520000.0002303 Hz
You’d use the “smallest of all” epsilon in a multiplied increment, perhaps to tick a value based on a knob or some such. Fine-tuning a VHF frequency with millihertz steps probably doesn’t make much practical sense.
The DDS frequency increment works out to 41.9095 mHz, slightly larger than with the Arduino, because it’s fot a cheap DDS eBay module with an AD9851 running a 180 MHz (6 × 30 MHz ) clock.
Propane Tank QD Fitting Adapter, PETG Edition
Posted by Ed in Home Ec, Machine Shop, Software on 2018-04-17
Smoking bacon during the winter months brought the third tank into play, requiring the POL-to-QD adapter I’d had in the drawer for just such an occasion. Not much to my surprise, the old PLA fitting adapter snapped along the layers near the outside end of the triangular snout:
IMG_20180408_125018
So I ran off the two orange ones in PETG with six perimeter layers and 50% infill density:
Propane QD Adapter Tool – Slic3r
Those should last roughly forever …
The OpenSCAD source code as a GitHub Gist:
Streaming Radio Player: CE Timing Tweak
Posted by Ed in Electronics Workbench, Software on 2018-04-16
Adding delays around the SPI control signal changes reduced the OLED glitch rate from maybe a few a week to once a week, but didn’t completely solve the problem.
However, (nearly) all the remaining glitches seem to occur while writing a single row of pixels, which trashes the rest of the display and resolves on the next track update. That suggests slowing the timing during the initial hardware setup did change the results.
Another look at the Luma code showed I missed the Chip Enable (a.k.a. Chip Select in the SH1106 doc) change in serial.py:
def _write_bytes(self, data):
gpio = self._gpio
if self._CE:
time.sleep(1.0e-3)
gpio.output(self._CE, gpio.LOW) # Active low
time.sleep(1.0e-3)
for byte in data:
for _ in range(8):
gpio.output(self._SDA, byte & 0x80)
gpio.output(self._SCLK, gpio.HIGH)
byte <<= 1
gpio.output(self._SCLK, gpio.LOW)
if self._CE:
time.sleep(1.0e-3)
gpio.output(self._CE, gpio.HIGH)
What remains unclear (to me, anyway) is how the code in Luma's bitbang class interacts with the hardware-based SPI code in Python’s underlying spidev library. I think what I just changed shouldn’t make any difference, because the code should be using the hardware driver, but the failure rate is now low enough I can’t be sure for another few weeks (and maybe not even then).
All this boils down to the Pi’s SPI hardware interface, which changes the CS output with setup / hold times measured in a few “core clock cycles”, which is way too fast for the SH1106. It seems there’s no control over CS timing, other than by changing the kernel’s bcm2708 driver code, which ain’t happening.
The Python library includes a no_cs option, with the caveat it will “disable use of the chip select (although the driver may still own the CS pin)”.
Running vcgencmd measure_clock core (usage and some commands) returns frequency(1)=250000000, which says a “core clock cycle” amounts to a whopping 4 ns.
Forcibly insisting on using Luma’s bitbang routine may be the only way to make this work, but I don’t yet know how to do that.
Obviously, I should code up a testcase to hammer the OLED and peer at the results on the oscilloscope: one careful observation outweighs a thousand opinions.
MPCNC: Linear Bearing Pen Holder
Posted by Ed in Machine Shop, Software on 2018-04-04
The simplest way to push a pen (or similar thing) downward with constant force may be to hold it in a linear bearing with a weight on it, so I gimmicked up a proof-of-concept. The general idea is to mount the pen so its axis coincides with the DW660 spindle, so as to have the nib trace the same path:
DW660 Pen Holder – unweighted
The puck mimics the shape of the DW660 snout closely enough to satisfy the MPCNC’s tool holder:
DW660 Pen Holder – Slic3r
The pen holder suffers from thin walls constrained by the 10 mm (-ish) pen OD and the 12 mm linear bearing ID, to the extent the slight infill variations produced by the tapered pen outline change the OD. A flock of 16 mm bearings, en route around the planet even as I type, should provide more meat.
In any event, 3D printing isn’t noted for its perfect surface finish, so I applied an epoxy layer and rotated the holder as it cured:
DW660 Pen Holder – epoxy coating
After letting it cure overnight, I ran a lathe tool along the length to knock down the high spots and set the OD to 11.9+ mm. Although the result turns out to be a surprisingly nice fit in the bearing, there’s no way epoxy can sustain the surface load required for the usual precision steel-on-steel fit.
A plastic pen in a plastic holder weighs 8.3 g, which isn’t quite enough to put any force on the paper. Copper weighs 9 g/cm³ = 9 mg/mm³ and 10 AWG wire is 2.54 mm OD = 5 mm², so it’s 45 mg/mm: to get 20 g, chop off 450 mm of wire.
I chopped off a bit more than that, straightened it, annealed it, and wound it around a random contestant from the Bucket o’ Sticks with an OD just over the pen OD:
DW660 Pen Holder – copper weight forming
The helix is 13.5 mm down the middle of the turns and 14 turns long (trimmed of the tail going into the chuck and fudging the tail sticking out as a partial turn), so it’s 593 mm long and should weigh 26.7 g. It actually weighs 27.6 g: close enough.
Which is enough to overcome stiction due to the holder’s surface roughness, but the mediocre epoxy-on-balls fit allows the pen point to wander a bit too much for good results.
The prospect of poking precise holes into 16 mm drill rod seems daunting, but, based on what I see here, it will produce much better results: rapid prototyping FTW!
The OpenSCAD source code as a GitHub Gist:
Sena PS410 Serial Server: Capturing HP 54602 Screen Images
Posted by Ed in Electronics Workbench, PC Tweakage, Software on 2018-04-03
The objective is to capture screen shots from my HP 54602 oscilloscope, now connected to Serial Port 1 of the Sena PS410 serial server.
Although the scope command language offers a :PRINT? command, it produces output in HP PCL, from which there seems no practical way to get a raster image format like PNG. So this remains an output-only transfer triggered by poking the PRINT SCREEN softkey, after first setting the serial parameters:
HP 54602 scope serial parameters
In text:
- Connect to: HP Plotter
- Factors: ON
- Resolution: HIGH
- Baud rate: 19200 b/s
- Handshake: XON
I have no idea what’s inside the serial cable at this late date (see the HP 8591 post for more musings), but the (paper!) manual says:
For three-wire operation, an XON/XOFF software handshake must be used to handle handshaking between the devices.
For extended hardwire operation, handshaking may be handled either with XON/XOFF or by manipulating the CTS and RTS lines of the oscilloscope.
For both three-wire and extended hardwire operation, the DCD and DSR inputs to the oscilloscope must remain high for proper operation.
With extended hardwire operation, a high on the CTS input allows the oscilloscope to send data and a low on this line disables the oscilloscope data transmission.
Likewise, a high on the RTS line allows the controller to send data and a low on this line signals a request for the controller to disable data transmission.
Since three-wire operation has no control over the CTS input, internal pull-up resistors in the oscilloscope ensure that this line remains high for proper three-wire operation.
Apparently, the DCD, DSR, and CTS inputs have internal pullups.
Hardware handshakings uses these signals:
- Pin 4 RTS (Request To Send) is an output from the oscilloscope which can be used to control incoming data flow.
- Pin 5 CTS (Clear To Send) is an input to the oscilloscope which controls data flow from the oscilloscope.
- Pin 6 DSR (Data Set Ready) is an input to the oscilloscope which controls data flow from the oscilloscope within two bytes.
- Pin 8 DCD (Data Carrier Detect) is an input to the oscilloscope which controls data flow from the oscilloscope within two bytes.
- Pin 20 DTR (Data Terminal Ready) is an output from the oscilloscope which is enabled as long as the oscilloscope is turned on.
The scope wiggles them thusly:
The TD (Transmit Data) line from the oscilloscope must connect to the RD (Receive Data) line on the controller. Likewise, the RD line from the oscilloscope must connect to the TD line on the controller.
The RTS (Request To Send) line is an output from the oscilloscope which can be used to control incoming data flow. A high on the RTS line allows the controller to send data, and a low on this line signals a request for the controller to disable data transmission.
The CTS (Clear To Send), DSR (Data Set Ready), and DCD (Data Carrier Detect) lines are inputs to the oscilloscope which control data flow from the oscilloscope (Pin 2). Internal pull-up resistors in the oscilloscope assure the DCD and DSR lines remain high when they are not connected.
If DCD or DSR are connected to the controller, the controller must keep these lines and the CTS line high to enable the oscilloscope to send data to the controller. A low on any one of these lines will disable the oscilloscope data transmission.
Dropping the CTS line low during data transmission will stop oscilloscope data transmission immediately.
Dropping either the DSR or DCD line low during data transmission will stop oscilloscope data transmission, but as many as two additional bytes may be transmitted from the oscilloscope.
The “as many as two additional bytes may be transmitted” suggests the same problem as with the HP 8591 spectrum analyzer at 19200 b/s, wherein it seems to overrun the PS410 input despite the flickering CTS control line.
I set up hardware handshaking in the PS410 and discovered the CTS line flickers as it does with the 8591, but the transfer complete without overruns. Perhaps the 8591 sends more than however many characters the PS410 can handle after calling for a pause?
The Kermit setup points to Serial Port 1 on the PS410:
set host 192.168.1.40 7001 /raw-socket set modem none
And then the rest of the script Just Works:
Calibrator waveform
The Kermit script as a GitHub Gist:
-
You are currently browsing the archives for the Software category.
Blowback