AVR Freaks

Who told you to use the ATMEGA?? You are using the WRONG device for this, forget about the ATMEGA

You need to use a DDS chip or PLL chip.  Do not use the ATMEGA, it will not have the fine freq resolution needed for ultrasonics, especially at these high frequencies. 

You will only later regret it when you need to tweak your frequency and can only take very large steps.  Usually you want to tune in a few Hz or 10's of Hz, maybe even 100Hz.  You will be very disappointed if you use the ATMEGA.

Do yourself a favor now and walk away, move on to a DDS or PLL.

What  avrcandies suggested is probably the right way to go.

Anyway, I made the changes. It can be further fine tuned.

void sendSignal()
{
    // Pin Low for 35 cycles

    PORTD &= ~(1 << PD3);

    asm volatile (
    "    ldi  r18, 11	\n"
    "1:  dec  r18	\n"
    "    brne 1b	\n"
    "    nop	\n"
    );

    // Pin High for 4 cycles

    PORTD |= (1 << PD3);

    asm volatile (
    "    lpm	\n"
    );

    // Pin Low for 67 cycles

    PORTD &= ~(1 << PD3);

    asm volatile (
    "    ldi  r18, 22	\n"
    "1:  dec  r18	\n"
    "    brne 1b	\n"
    );

    // Pin High for 4 cycles

    PORTD |= (1 << PD3);

    asm volatile (
    "    lpm	\n"
    );

    // Pin Low for 35 cycles

    PORTD &= ~(1 << PD3);

    asm volatile (
    "    ldi  r18, 11	\n"
    "1:  dec  r18	\n"
    "    brne 1b	\n"
    "    nop	\n"
    );

    // Pin High for 4 cycles

    PORTD |= (1 << PD3);

    asm volatile (
    "    lpm	\n"
    );

    // Pin Low for 66 cycles

    PORTD &= ~(1 << PD3);

    asm volatile (
    "    ldi  r18, 21	\n"
    "1:  dec  r18	\n"
    "    brne 1b	\n"
    "    rjmp 1f	\n"
    "1:	\n"
    );

    // Pin High for 4 cycles

    PORTD |= (1 << PD3);

    asm volatile (
    "    lpm	\n"
    );

    // Pin Low for 25 cycles

    PORTD &= ~(1 << PD3);

    asm volatile (
    "    ldi  r18, 8	\n"
    "1:  dec  r18	\n"
    "    brne 1b	\n"
    );

    // Pin High for 4 cycles

    PORTD |= (1 << PD3);

    asm volatile (
    "    lpm	\n"
    );

    // Pin Low for 16 cycles

    PORTD &= ~(1 << PD3);

    asm volatile (
    "    ldi  r18, 5	\n"
    "1:  dec  r18	\n"
    "    brne 1b	\n"
    );

    // Pin High for 4 cycles

    PORTD |= (1 << PD3);

    asm volatile (
    "    lpm	\n"
    );

    // Pin Low for 16 cycles

    PORTD &= ~(1 << PD3);

    asm volatile (
    "    ldi  r18, 5	\n"
    "1:  dec  r18	\n"
    "    brne 1b	\n"
    );

    // Pin High for 4 cycles

    PORTD |= (1 << PD3);

    asm volatile (
    "    lpm	\n"
    );

    // Pin Low for 16 cycles

    PORTD &= ~(1 << PD3);

    asm volatile (
    "    ldi  r18, 5	\n"
    "1:  dec  r18	\n"
    "    brne 1b	\n"
    );

    // Pin High

    PORTD |= (1 << PD3);

}

void setup() {

    DDRD |= (1 << PD3);
    PORTD |= (1 << PD3);
}

void loop() {

    sendSignal();
    delay(100);
}

The OP looks to be cloning an existing system pulse stream where only a single pulse is given with varying delays.

Thus KISS of inline ASM with defined delays looks just fine - easy to adjust.

You need to rethink that.  At full 20MHz that is 50ns per tick, a HUGE amount near 1 MHz

say you want to gen 1000000 Hz, that's 20 AVR ticks for either freq or equiv delay between 2 pulses

say you want to gen 1000250 Hz that's 19.995 ticks for either freq or equiv delay between 2 pulses

You can see the resolution is extremely low & the AVR should be replaced by something else.

You need to use a DDS chip or PLL chip.  Do not use the ATMEGA, it will not have the fine freq resolution needed for ultrasonics, especially at these high frequencies. 

You will only later regret it when you need to tweak your frequency and can only take very large steps.

I think that many of the comments above are trying to understand what you are trying to do.... and to understand how well you understand the design requirements.

Sometimes one (we have all done it) optimise some aspect perfectly... only to learn that +/- 20% (100%?) might have been OK. Understanding the details of how and why a system works (or doesn't) lets us all make good design decisions as to what matters more and less.

Do you feel you have a good understanding of the operation and critical aspects of the system you are planning to duplicate?

If you want to recreate the signal that produced the scope shot in the opening post then stop thinking in terms of frequency and duty cycle and start thinking in terms of time. You need to load timer registers with the number clock pulses to be high and the number between pulses, so let's just work with integers numbers of clock pulses. The ATmega328P runs at 16MHz. That means one clock pulse is 1/(16MHz) = 1/16us. That's 1/16 of one horizontal division on the scope.

In the photo, ignore the text added showing frequencies and duty cycles; they're wrong. Proof is the fact that the longest period is marked 792KHz and the shortest 226KHz. Higher frequencies have shorter periods and vice versa, so let's just look at the photo and try to tell how many clock cycles long each feature is.

Ok, I already did the hard work. What I did was load the photo into a drawing program that shows the x and y coordinates of whatever pixel you point at. (I used Pinta, but MS Paint would probably work just as well.) I went across and recorded the horizontal position of each vertical division on the scope. I fit a straight line to those numbers and got an equation that returns a time in microseconds given a horizontal position in pixels. I then went across and recorded the position of each transition. I took every measurment along the horizontal division just below the peak in the pulses. That method should compensate for parallax in the photo.

The width of each pulse is about 0.25 us, or 4 clock cycles at 16MHz. There's 16 transitions on the scope with only 7 actual pulses. If we assume there's a pulse hidden at one end or the other of the stream, then we can find 8 periods as shown below. My measurement came up with 1.22 us period for the 5th one while the cursors on the scope show 1.26 us. Take that however you want.

The period in clock cycles is in the first column with the remaining columns showing the corresponding number of clock cycles for different clock frequencies. Notice that at 16MHz the shortest pulse is only about 13 cycles. If the pulse is high for 4 cycles then it's low for 9. I'm not sure when you would have time to change the values in the timer registers.

I included a column for 80MHz because that's how fast the peripheral clock runs in the ESP32. That's an interesting microcontroller because it has a cool peripheral intended to send signals to an IR LED for remote control (RMT.) The way it works is that you put values in an array that say how long (in clock cycles) you want the LED to be on and off for each pulse in the stream. When you tell it to go it spits out the signal. Exactly what you want.

I used the oscilloscope to measure the time period for each pulse

Hardly! Only in the very crudest sense...you had next to NO accuracy, at least in terms of any precision work.  Ok, you see half a division, maybe 3/4th division, or maybe 5/8ths or even 9/16th  NONE of that is very good.  ...it's simply not precision work.

One percent, which is still barely accurate, means you'd take a block and divide it into 100 slices (assuming 100% is approx one full block)---can you see the block sliced up that fine?

I already mentioned you need to zoom in, or use the dual timebase feature to measure time accurately.  Also this assumes straight edges, not curvy wiggly edges (more uncertainty).

Also if you are measuring all these times, why are you mentioning up frequency at all?   Makes no sense whatsoever & quite misleading.

Again, just because the pulses were generated with this particular time separation doesn't mean you can't use your own separation. It really seems like you are blindly trying to copy things. Who said you need 8 pulses?  How about 4 or 20? Why 8?

Try some of your own experiments--that is the real learning.   You made a rough start on your journey, now it is time to get to work.

What I see is a waveform with 15 different width pulses: some high, some low. So I'd write code to generate that. At this stage I'd even think about doing it with strings of NOPs. Forget timers and other such complications, it all an overhead. At  this time we're in the research phase, we aren't even close to development. Or don't people do it this way any more? 

Like that I could start at the beginning and tweak each one individually for resonance (or whatever it is the OP is looking for).

According to the reference manual, the default (and highest) frequency is 80 MHz. I have never used an ESP32, but I once considered try to use the RMT to measure the duty cycles of an incoming stream. I ended up going in a different direction....

I might be mistaken, but I don't think he does have the waves, only photos of a scope.

Anyway, I kind of enjoy the process of extracting accurate data from an image. It's fun. You don't want to take that away from me, do you?

As promised, here's my code submission. The OPS's code is Arduino format, so mine takes the same form. I tested it on a Sparkfun Pro Micro with ATmega32U4 and found that it reproduces the known-to-be-good signals in post #31 pretty well.

Essentially this just unrolls the string of transitions. Each instruction to change PORTB takes 2 clock cycles. The remaining time is consumed with NOPs which (obviously) are 1 cycle each. At 16 MHz each clock cycle is 62.5 us.

I had to guess about the time that the pulses are high. From the photos it looks like they are high for somewhere between 4 and 6 cycles. It's difficult to tell because that pin is apparently capacitively loaded, perhaps by the piezo. This code has the high time set to 5 cycles (1 write to PORTB + 3 NOP.) That can be shortened by commenting out a NOP from each section where the pin is high and uncommenting one NOP from each section where the pin is low.

A cursory look at the OP's code suggested that TIMER1 is outputting on PB1. This code doesn't use any timers, but directly writes to PORTB.

I would like to see what kind of response is generated on the OP's system. (I.e.. what does the blue trace look like when fed this yellow trace.) It can be used as a ready to go Arduino sketch, or copy the SendPulses() function into your own code.

#define NOP __asm__ __volatile__ ("nop\n\t")

void SendPulses()
{
  /* This routine generates a series of transitions on PB1. 
   *
   * Each transition (PORTB = ...) takes two clock cycles.
   * 
   * Remaining time is filled with NOP. Obviously, 1 clock cycle per NOP
   * 
   * Each clock cycle is 1/16 = 62.5 us
   */ 
   // start of pulse #1
   PORTB &= ~_BV(PORTB1); //set PB1 low
   NOP; //1
   NOP; //2
   NOP; //3
   NOP; //4
   NOP; //5
   NOP; //6
   NOP; //7
   NOP; //8
   NOP; //9
   NOP; //10
   NOP; //11
   //NOP; //12
   //NOP; //13

   PORTB |= _BV(PORTB1); //set PB1 high
   NOP; //1
   NOP; //2
   NOP; //3
   //NOP; //4
   //NOP; //5

   // start of pulse #2
   PORTB &= ~_BV(PORTB1); //set PB1 low
   NOP; //1
   NOP; //2
   NOP; //3
   NOP; //4
   NOP; //5
   NOP; //6
   NOP; //7
   //NOP; //8
   //NOP; //9
   //NOP; //10
   //NOP; //11
   //NOP; //12
   //NOP; //13

   PORTB |= _BV(PORTB1); //set PB1 high
   NOP; //1
   NOP; //2
   NOP; //3
   //NOP; //4
   //NOP; //5

   // start of pulse #3
   PORTB &= ~_BV(PORTB1); //set PB1 low
   NOP; //1
   NOP; //2
   NOP; //3
   NOP; //4
   NOP; //5
   NOP; //6
   NOP; //7
   NOP; //8
   NOP; //9
   NOP; //10
   NOP; //11
   //NOP; //12
   //NOP; //13
  
   PORTB |= _BV(PORTB1); //set PB1 high
   NOP; //1
   NOP; //2
   NOP; //3
   //NOP; //4
   //NOP; //5
	
   // start of pulse #4
   PORTB &= ~_BV(PORTB1); //set PB1 low
   NOP; //1
   NOP; //2
   NOP; //3
   NOP; //4
   NOP; //5
   NOP; //6
   NOP; //7
   //NOP; //8
   //NOP; //9
   //NOP; //10
   //NOP; //11
   //NOP; //12
   //NOP; //13
	
   PORTB |= _BV(PORTB1); //set PB1 high
   NOP; //1
   NOP; //2
   NOP; //3
   //NOP; //4
   //NOP; //5
	
   // start of pulse #5
   PORTB &= ~_BV(PORTB1); //set PB1 low
   NOP; //1
   NOP; //2
   NOP; //3
   NOP; //4
   NOP; //5
   NOP; //6
   NOP; //7
   NOP; //8
   NOP; //9
   NOP; //10
   NOP; //11
   NOP; //12
   NOP; //13

   PORTB |= _BV(PORTB1); //set PB1 high
   NOP; //1
   NOP; //2
   NOP; //3
   //NOP; //4
   //NOP; //5
	
   // start of pulse #6
   PORTB &= ~_BV(PORTB1); //set PB1 low
   NOP; //1
   NOP; //2
   NOP; //3
   NOP; //4
   NOP; //5
   NOP; //6
   NOP; //7
   NOP; //8
   NOP; //9
   NOP; //10
   NOP; //11
   //NOP; //12
   //NOP; //13
	
   PORTB |= _BV(PORTB1); //set PB1 high
   NOP; //1
   NOP; //2
   NOP; //3
   //NOP; //4
   //NOP; //5
	
   // start of pulse #7
   PORTB &= ~_BV(PORTB1); //set PB1 low
   NOP; //1
   NOP; //2
   NOP; //3
   NOP; //4
   NOP; //5
   NOP; //6
   NOP; //7
   NOP; //8
   NOP; //9
   NOP; //10
   NOP; //11
   NOP; //12
   //NOP; //13
	
   PORTB |= _BV(PORTB1); //set PB1 high
   NOP; //1
   NOP; //2
   NOP; //3
   //NOP; //4
   //NOP; //5
	
   // start of pulse #8
   PORTB &= ~_BV(PORTB1); //set PB1 low
   NOP; //1
   NOP; //2
   NOP; //3
   NOP; //4
   NOP; //5
   NOP; //6
   //NOP; //7
   //NOP; //8
   //NOP; //9
   //NOP; //10
   //NOP; //11
   //NOP; //12
   //NOP; //13

   PORTB |= _BV(PORTB1); //set PB1 high
}

void setup()
{
   DDRB |= _BV(DDB1);    //set PB1 as output
   PORTB |= _BV(PORTB1); //set PB1 high
}

void loop()
{
   SendPulses();
   delay(1000);
}

The Doc beat me to it, but for this app, the 8 pulses most likely all need to be the same period, that is near the resonance of the transducers.  Unless some type of modulation is being used, what for is unknown to me.

one could use the spi, or better the USART in SPI mode to send the pulses at 1MHz.  PWM could be used if modulation is needed, but that is out of the realm for an AVR at that freq.
As Doc said, the sending is the easy part, receiving, detecting and timing the echo is the fun part…

fly over Jim

Looking more closely at all of the photos, it looks like the first resonance of the piezo is around 1MHz. Looking more closely, it's apparent that there's another resonance at around 2.5MHz. That's the one that seems to be excited by the pulses.

The other weird thing is that the pulses start and stop abruptly with the pulse. Looking at the photo from post #31 (old image from when the system worked correctly.) Comparing the input to the output, I can see that the output started at the rising edge of the pulse (but not at the very beginning of the pulse.) But then it ends abruptly some 200ns after the falling edge of the pulse. Makes me wonder.... Is there a MOSFET across the piezo that keeps it shorted when the pulse is high, but 'releases' it when the pulse is low? Is that little jaggie at the start of the pulse there because the pulse is connected to the gate of the MOSFET? Does the pulse not get damped immediately because it takes 200ns for the MOSFET to turn off? (Seems a long time.)

Meanwhile, later photos with the 'emulated' pulses show ringing while the pulses are low. Another observation: in the first photo the input signal is less than 1V, yet in the later photo, with the ringing, it's close to 5V and square edged. What's going on? Is there something else wrong with this equipment?

Not sure what to make of the fact that the pulses are inverted. When 'high' they're close to, or just below 0V. When 'low' they're more negative. Only about -1.5V in the old photos. Exactly where were you probing here?

Would be nice to see the circuit and where the probes are placed. Probably pretty simple once you understand it, but there's definitely something unconventional. Well, it might be conventional in this specific application, but it's not familiar to me.

Edit: I suppose a series combination of a piezo and a transistor across some power supply would explain it all pretty simply. Still not sure why the pulses are irregularly spaced. It's way easier to make them periodic.

According to DocJC (and my existing understanding) if you want to get a system vibrating at resonance with maximum amplitude, you need to hit it repeatedly at its resonant frequency. I can tell from the photos that the first resonance is about 1MHz with another (probably second) resonance around 2.5MHz. In other words, if you're using pulses in a way described by DocJC, then you want the pulses to be evenly spaced at 1/(1MHz) = 1us. Using eight pulses that are scattered in period around 1 us is not a good thing. Think about pushing a child on a swing. You give a little push exactly when the swing reaches the top and starts moving in the other direction. If you push too soon it slows the swing down. It's not a perfect analogy, but it's close enough.

One possibility (that I doubt) is that the device is trying to generate a period that is not an even multiple of its main clock period. The only DDS chip that I have used (from Analog Devices - don't remember the part number) produced squarish waves with a remarkable advertised frequency resolution considering its internal clock frequency. For the sake of discussion, suppose it has an internal clock of 100MHz. That's a clock period of 10 ns. So we all understand how to use a counter/timer to generate slower square waves. As long as the total period is an even multiple of 10ns (call it N with N=2, 4, 6, 8, 10, ....) then we keep the wave high for N/2 and low for N/2 clocks. A 25 MHz square is 2 cycles high and 2 cycles low. The next lowest frequency is 3 high and 3 low = 16.7 MHz. If you asked it for 20 MHz then it would intersperse equal numbers of 2 high /2 low with 3 high / 3 low. If you asked for 20.5MHz, then it produce slightly more 3H/3L than 2H/2L. Maybe it would put in some 3H/2L and 2H/3L as well, I don't know, but you get the point. If you fed that into a spectrum analyzer, the largest component would be 20.5 MHz, but there would be a lot of other nearby frequencies too.

I can imaging a similarly clever pulse generator that is working with a 32 MHz clock. Ask it to produce 4 us pulses @ 1 MHz and it will produce a string of 8H/24L. The total period is 32 clocks which is exactly 1MHz. But suppose you ask it for 1.01MHz. The pulses still need to be 4H, but it can't do 26.5L so it does 4H/26L and then 4H/27L. Now suppose you ask for 8 pulses @ 1.0085 MHz. I'm not going to try to figure it out, but the spaces between pulses would not be consistent. In our case the pulses seem too inconsistent for even something like that, so I doubt that's what's going on, but maybe...

Anyway, it's time for the OP to show us what's behind the curtain. Tell us the make and model of instrument you're working with. Tell us what you've figured out about the circuit and where you're putting the scope probes. Show us some clear photos of the PCB. Take it all off.