Signals and Systems for Dummies

I have the book:

formatting link

Here's my DDS sim. A tiny ARM cpu generates a DDS sine wave in software, with a 50 KHz interrupt rate and its internal 10 bit DAC. The spice sim uses a sample+hold and quantizer to simulate that.

When V4 is around 400 Hz, the output looks really nice. At, say, 5377 Hz, you can zoom in on the voltage peaks and see them getting ragged. The FFT shows the corresponding sidebands around 50 KHz.

This stuff is fun, in a geeky sort of way. Better than working on the deck.

The filter was made from parts that were already on the pcb BOM; it's not bad.

Version 4 SHEET 1 2228 980 WIRE 176 -208 112 -208 WIRE 400 -208 176 -208 WIRE 112 -160 112 -208 WIRE 624 -160 576 -160 WIRE 688 -160 624 -160 WIRE 1024 -160 816 -160 WIRE 1168 -160 1104 -160 WIRE 400 -144 304 -144 WIRE 816 -96 816 -160 WIRE 304 -80 304 -144 WIRE 112 -48 112 -80 WIRE 816 16 816 -16 WIRE 304 48 304 0 WIRE 1760 96 1728 96 WIRE 1760 128 1760 96 WIRE 368 144 304 144 WIRE 400 144 368 144 WIRE 608 144 560 144 WIRE 640 144 608 144 WIRE 1024 144 816 144 WIRE 1168 144 1168 -160 WIRE 1168 144 1104 144 WIRE 1248 144 1168 144 WIRE 1392 144 1328 144 WIRE 1456 144 1392 144 WIRE 1600 144 1536 144 WIRE 1728 144 1600 144 WIRE 1824 160 1792 160 WIRE 1888 160 1824 160 WIRE 1920 160 1888 160 WIRE 1728 176 1680 176 WIRE 304 208 304 144 WIRE 560 208 560 144 WIRE 816 208 816 144 WIRE 1168 208 1168 144 WIRE 1392 208 1392 144 WIRE 1600 208 1600 144 WIRE 1760 224 1760 192 WIRE 1760 224 1728 224 WIRE 1168 304 1168 272 WIRE 1600 304 1600 272 WIRE 304 336 304 288 WIRE 560 336 560 288 WIRE 816 336 816 288 WIRE 1392 368 1392 272 WIRE 1680 368 1680 176 WIRE 1680 368 1392 368 WIRE 1824 368 1824 160 WIRE 1824 368 1680 368 FLAG 1600 304 0 FLAG 1728 224 P FLAG 1728 96 N FLAG 1888 160 OUT FLAG 304 336 0 FLAG 560 336 0 FLAG 368 144 P FLAG 608 144 N FLAG 1168 304 0 FLAG 112 -48 0 FLAG 176 -208 GEN FLAG 304 48 0 FLAG 816 16 0 FLAG 816 336 0 FLAG 624 -160 S SYMBOL res 1120 128 R90 WINDOW 0 -50 55 VBottom 2 WINDOW 3 -42 58 VTop 2 SYMATTR InstName R1 SYMATTR Value 1K SYMBOL cap 1152 208 R0 WINDOW 0 -69 28 Left 2 WINDOW 3 -74 66 Left 2 SYMATTR InstName C1 SYMATTR Value 27n SYMBOL res 1344 128 R90 WINDOW 0 -50 55 VBottom 2 WINDOW 3 -42 58 VTop 2 SYMATTR InstName R3 SYMATTR Value 5K SYMBOL res 1552 128 R90 WINDOW 0 -52 63 VBottom 2 WINDOW 3 -42 61 VTop 2 SYMATTR InstName R4 SYMATTR Value 5K SYMBOL cap 1376 208 R0 WINDOW 0 -67 31 Left 2 WINDOW 3 -71 68 Left 2 SYMATTR InstName C3 SYMATTR Value 10n SYMBOL cap 1584 208 R0 WINDOW 0 -71 32 Left 2 WINDOW 3 -67 68 Left 2 SYMATTR InstName C4 SYMATTR Value 1n SYMBOL Opamps\\UniversalOpamp2 1760 160 M180 WINDOW 0 28 46 Left 2 SYMATTR InstName U2 SYMBOL voltage 304 192 R0 WINDOW 0 58 46 Left 2 WINDOW 3 62 86 Left 2 SYMATTR InstName V2 SYMATTR Value 5 SYMBOL voltage 560 192 R0 WINDOW 0 58 46 Left 2 WINDOW 3 62 86 Left 2 SYMATTR InstName V3 SYMATTR Value -5 SYMBOL voltage 112 -176 R0 WINDOW 0 38 139 Left 2 WINDOW 3 -33 185 Left 2 WINDOW 123 27 173 Left 2 WINDOW 39 0 0 Left 2 SYMATTR InstName V4 SYMATTR Value SINE(0 1 5377) SYMBOL SpecialFunctions\\sample 480 -176 R0 WINDOW 0 -12 -40 Left 2 SYMATTR InstName A1 SYMBOL voltage 304 -96 R0 WINDOW 0 66 100 Left 2 WINDOW 3 39 138 Left 2 WINDOW 123 27 173 Left 2 WINDOW 39 0 0 Left 2 SYMATTR InstName V5 SYMATTR Value PULSE(0 2 0 1u 1u 5u 20u) SYMBOL voltage 816 -112 R0 WINDOW 0 87 23 Left 2 WINDOW 3 55 64 Left 2 WINDOW 123 71 108 Left 2 WINDOW 39 0 0 Left 2 SYMATTR InstName V1 SYMATTR Value SINE(0 1 1K) SYMATTR Value2 AC 1 SYMBOL res 1120 -176 R90 WINDOW 0 -50 55 VBottom 2 WINDOW 3 -42 58 VTop 2 SYMATTR InstName R2 SYMATTR Value 1T SYMBOL bv 816 192 R0 WINDOW 3 20 121 Left 2 WINDOW 0 62 40 Left 2 SYMATTR Value V=int(512.5*V(s))/512 SYMATTR InstName B1 TEXT 1616 -72 Left 2 !.tran 0 100m 0 500n TEXT 1232 -104 Left 2 ;P540 10KHz 3P DDS LPF TEXT 1288 -8 Left 2 ;JL Oct 21, 2017 TEXT 592 -112 Left 2 ;SAMPLER TEXT 360 -40 Left 2 ;50 KHz IRQ TEXT 1616 -16 Left 2 !;ac dec 20 1K 100K TEXT 864 272 Left 2 ;QUANTIZER TEXT 1256 -56 Left 2 ;10 BIT DDS AT 50 KHZ

--
John Larkin         Highland Technology, Inc 

lunatic fringe electronics
 Click to see the full signature
Reply to
John Larkin
Loading thread data ...

John Larkin wrote on 10/21/2017 1:03 PM:

Driving timing from an interrupt can add jitter. Better to use a part with DMA driving the ADC. The the software timing only needs to keep up with the data rate keeping the DMA buffer full. The only jitter will be from the actual clock and not any clock cycle level jitter in the CPU.

--
Rick C 

Viewed the eclipse at Wintercrest Farms, 
 Click to see the full signature
Reply to
rickman

Interrupt jitter isn't that big a problem on RISC processors; well 8 bit AVRs, at least - the only jitter in the interrupt timing is due to the fact that not all instructions take exactly one cycle to complete and the ISR can't execute until whatever it is is done, but nearly all take a single cycle, some take two, and a very small number take four. The typical jitter isn't more than one clock slow or fast, and if you're running it at 20MHz and using a 16 bit counter that's going to be about a thousandth of a percent of the PWM base frequency.

Reply to
bitrex

It ain't zero and using DMA works a lot better in that regard.

--
Rick C 

Viewed the eclipse at Wintercrest Farms, 
 Click to see the full signature
Reply to
rickman

It is something like 0.1%, not 0.001%

Reply to
Klaus Kragelund

U.

Best I could do with a 20MHz Atmel chip was as expected, 50 nS jitter in designing a laser range tester. Gave a resolution of 15M over

10Km.Plenty good enough for testing...
--
This email has been checked for viruses by Avast antivirus software. 
https://www.avast.com/antivirus
Reply to
TTman

Yes, tens of ns out of 20 us is ballpark 0.1% DAC clock period jitter. A 400 Hz sine wave doesn't change much in 20 ns. Nyquist is 25 KHz!

If Ricky wants to make a technical point, and not just do his customary whining, he can add jitter to my sim clock and post the results.

--
John Larkin         Highland Technology, Inc 

lunatic fringe electronics
 Click to see the full signature
Reply to
John Larkin

John Larkin wrote on 10/21/2017 6:33 PM:

Why should anyone want to simulate the impact of unneeded jitter? It is such a simple matter to get rid of it. Besides, there are equations that relate clock jitter to distortion in sine wave. Why would you simulate something you can calculate? Oh, I forgot, you are math challenged.

I'll give you a hint. 0.1% jitter in a sine wave sampling clock is not trivial. But I'm sure it is small enough that you won't see the increased "ragged" parts of the voltage peaks. The eye is a terrible way to measure distortion.

--
Rick C 

Viewed the eclipse at Wintercrest Farms, 
 Click to see the full signature
Reply to
rickman

On a sunny day (Sat, 21 Oct 2017 23:00:03 +0100) it happened TTman wrote in :

I did a sine generator in the eighties, it consisted of a CD4040 CMOS counter driving the address pins of an EPROM with a sine table. the counter was clocked by a CD4046 PLL. There also was a triangle wave generator (opamp integrator) and 2 comparators on the VCO control voltage so it could sweep up and down, used it measure filters. You could use 16 bit EEPROM sine table too of course, or 32 if you are into that. What DAC did I use? Was it r2r or some chip? do not remember. No jitter. Could be frequency locked, to x time input, for 400 Hz, use a counter output = 8 x 50 Hz mains here,,, Who needs a micro? I did however have some 8051s at that time. But just build that on verobard in an afternoon to test some stuff.

Reply to
Jan Panteltje

Exactly. Basing any form of signal synthesis on interrupts, which introduce unpredictable latencies (especially in the case of nested interrupts) and can be disabled is asking for trouble. OTOH, it is a bitter irony that the mechanisms to flawlessly perform this kind of real-time tasks have been introduced relatively recently to the MCU world.

Best regards, Piotr

Reply to
Piotr Wyderski

If it is not needed, then it doesn't work better

I use DMA when I can, but an interrupt it a lot easier to set up then a DMA

Sometimes noise is actually good. Say you want to oversample/average an ADC input. If it is rock steady, oversampling does no good

Cheers

Klaus

Reply to
Klaus Kragelund

So you intend to use a possibly interrupt to precalculate one or more samples (phase accumulator update, sine look-up etc.) into a memory buffer and then let a DMA transfer multiple samples from that memory buffer to the DAC.

Precalculating multiple samples during a single interrupt saves on interrupt overhead, but how do you synchronize DMA transfers with interrupts ?

Of course, if the frequency is not changing rapidly, you could precalculate the samples even with some scripting language :-) The buffer might be quite big to avoid jumps, when the sequence starts over.

It would be simpler to use a common clock to drive both the interrupt pin and DAC latch pin. While there will be added jitter due to interrupts, but as long as the next sample value can be calculated prior to the _next_ DAC clock transition, the timing remains perfect.

Reply to
upsidedown

Driving from interrupts may be satisfactory in this case, but in general it is an orange flag.

I don't know whether that "tiny ARM" has caches, but caches are /designed/ to right royally "influence" timing.

There is another alternative. Have an IO port with inbuilt timer, and instruct the port to output the next value when the counter reaches X. It helps if the counter's clock frequency is high (say >=100MHz), there are no caches, and the hardware and software are well integrated (e.g. xC and xCORE).

Reply to
Tom Gardner

The 400 Hz generator works fine. I'm just tweaking the filters and stuff now, and deciding on specs.

We have one product that has an isolated LPC1764 per channel, 12 channels on the board. Arrow programs the chips for us so we just solder them down. Each runs a pretty fancy ADC/filter/PID/SPI loop, irq at 100 KHz. I had my programmer guy bring up a port pin at the start of the ISR and drop it just before RTI. On a scope, the width jitters a bit from different execution paths, but the period looks like it came from a pulse generator. We cranked down the CPU clock rate until we got about 50% IRQ duty cycle, to save power.

There were no other interrupts, and interrupts were never disabled in the main loop. Each CPU has only one thing to do.

DAC load jitter didn't matter in that case, but for my 400 Hz DDS, I could load the DAC at the start of the ISR, and then compute the next point. But that simple DDS code is probably runtime invariant anyhow.

Really, a 100 MHz RISC cpu has tiny interrupt latency. My DAC quantization and cheap 3-pole single-opamp lowpass filter are the big errors here. And the DDS math itself.

Here's my board so far. I like to lay out a small board myself, now and then.

formatting link

--
John Larkin         Highland Technology, Inc 

lunatic fringe electronics
 Click to see the full signature
Reply to
John Larkin

The LPC1764 runs code out of flash. It has some sorta-cache thing ...

"Enhanced flash memory accelerator enables high-speed 120 MHz operation with zero wait states"

whatever that means. On a scope, interrupts look perfectly periodic.

We're using the ARM's internal 10-bit DAC. It's simple. So many people are telling me that it doesn't work, except that it does.

--
John Larkin         Highland Technology, Inc 

lunatic fringe electronics
 Click to see the full signature
Reply to
John Larkin

No doubt that's a case of RTverylongFMs :(

Whether that is sufficient is application dependent, of course. No doubt the audiophools wouldn't be impressed!

Very application and board dependent, of course.

I always take the attitude that there are lies, damned lies, statistics, and ADC/DAC specs.

Reply to
Tom Gardner

This ARM's ADC is especially bad. Not very linear, and occasionally makes giant code spikes.

--
John Larkin         Highland Technology, Inc 

lunatic fringe electronics
 Click to see the full signature
Reply to
John Larkin

ystems+dummies

The

7
.
e
s
t

up

be

.

al it

ned/

with

most of the cortexs with flash does similar things, the flash is 128bit wide so it can run at ~1/8 the rate of the cpu and still keep up, and then it has a number of 128bit registers to try account for when the code isn't linear

it won't always be zero waitstates but it'll usually be close

it is only 400Hz, if my math isn't too far off that has a maximum slewrate of 1 lsb per 40us for a 10 bit converter

Reply to
Lasse Langwadt Christensen

The STM32F2 series is like that too, in fact most of the higher speed STM32s are AFAICT. It is apparently due to big spikes from the flash accelerator.

However we used the STM32F301 recently in a project, this seemed to be rather quiet to my surprise, as good as a discrete ADC. And very cheap for a CM4. Don't know about linearity since this was not so important for us.

--

John Devereux
Reply to
John Devereux

We use that NXP series of chips in one product. They work pretty well. The cache is kinda limited but enough to pre-read instructions from flash and to feed to the ARM registers for fast processing... Unless that is, an instruction needs another flash word away from that small-ish cache buffer area.

The peripherals can be pretty much anything the vendor (NXP, ST, whoever) puts in along with the ARM processor itself AFAIK.

I hadn't encountered any spikes per se' but will have to take a look. We use STM32F4xx and STM8... But we also use external Delta-Smegma A/Ds which shouldn't have much of a problem related to the micro it is connected to unless we are sloppy with our layout which can certainly happen from time to time.

boB

Reply to
boB

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.