OWON VDS1022 EXT trigger

[dizcza]

Hi there,
I haven't found a forum dedicated to OWON scopes and have noticed you guys have been discussing VDS1022 here, on EEVblog. So I decided to post my question here.
The VDS1022I manual (I followed Dave's advice and bought the model with a USB isolation) says that the EXT (MUTLI) channel can be used as the trigger for CH1 and CH2 but it does not describe the steps to follow.
I'm trying to spot misfunction of a DS3231 module with this scope by inspecting the SQW output. Usually, it's 1024 Hz as it should, but occasionally the period between two events gets two times smaller (488 us instead of 976) and this screws up my ESP32 board running some logic. It happens rarely (once per hour) so I cannot monitor the SQW pin all time.
So I want to set some unused GPIO of ESP32 to output and set it to high when the period between two SQW spikes is ~488 us. When this pin goes high, I want my VDS1022I to capture the picture of SQW and freeze it for further inspection. How to set up VDS1022I to do so? The setup I've tried (see pictures below) led me to nothing - nothing is triggered.
Thanks.

[Bigwizman]

Hi dizcza,

I've recently bought a VDS1022i myself and have been looking at EXT trigger.  I've posted a couple of my findings on the teardown page that Gyro started several years ago.  My unit does trigger from external signals but has some foibles, one being it only responds to rising edges, it doesn't respond to negative edges and to get reliable triggering the trigger needs to traverse very slightly negative to the 0v line, although be careful if you try this as you could easily overload the protection diodes.

However, from what you are asking the DS3231 SQW pin is a multipurpose pin but I assume you are just trying to catch when it has a different timing (it could be it has detected an alarm time match)?  From this assumption, I would suggest you do not need EXT triggering, as the normal triggering on CH1 & 2 are far more powerful than the edge only available on EXT.  My advice would be to use the pulse triggering set to respond when the pulse width is less than the normal time expected (it is a mode not available on many other scopes).  This will work in both single shot trigger mode or normal but normal will re-trigger each time the short pulse is detected.  If you need to catch what other signals are doing when the trigger state is detected, then you have the other channel to view those relative to the trigger time (either before or after the trigger indicator, although you may need to adjust the timebase to capture a longer period or adjust the pre & post trigger position, so might need several captures before you can make any conclusions).  There is a caveat however, as the Owon software, does not trigger on slower timebases when the display goes into roll mode.  I assume you don't need the slow timebase.

Best regards.

[dizcza]

Thanks for the descriptive reply, I wasn't aware of the EXT falling edge issue.

Yeah, I also switched to the pulse width triggering. Here are the pictures I captured. So I'm getting an extra tick from the SQW pin, I haven't tested whether this corresponds to setting the clock time on the DS3231. I didn't find anyone describing such issues with this module. Another thing happening to DS3231 is that sometimes SQW resets to the default 1 sec period as if it loses power occasionally. Caps don't help.

Capturing a 1 sec width pulse with the 10 MSa/sec rate won't work on VDS1022. I need to resort to other methods... or give up and account for occasional RTC resets.

[Bigwizman]

Hi dizcza,

Glad you resorted to pulse trigger, it is bonus on this scope.  Your two captures have different conclusions from what I can see.  The 1st appears to be a restart of the 1024Hz SQW after the erroneous 100uS pulse but the 2nd capture isn't starting again, almost like it restarted part way through the erroneous pulse.  Have you checked that you are not altering anything in the configuration for the multiple outputs that SQW can be set for?  Alarms are the most obvious, as they can be set for regular time periods from memory.

Your comment about a 1 sec pulse train (I assume you mean if you have to settle for that as a more reliable output) isn't clear.  The VDS1022 can be set for slow sweep speed and still capture fast transients by using peak detect rather than samples, as the ADC is still running at 100MS/s, despite only a lower number being used for the display.  Your picture will appear noisy, as all the tiny changes will show and if you are on slow sweep no trigger on the Owon software but it is easy enough to just stop the trace using the stop button top right of the display.  There is a third part software that the other members have spent effort on that does allow triggering in roll mode that could be another option.  Not understanding your comment, I can't advise any better.

Do you have a battery in your test circuit, as that should stop powerline issues.  If you are on breadboard, it could very well be glitches.  You don't want to be searching for non-issues but layout could also be causing pick-up or crosstalk on fast edges, moving things might help eliminate things that aren't what you expect to see.

Best regards.

[dizcza]

Have you checked that you are not altering anything in the configuration for the multiple outputs that SQW can be set for?  Alarms are the most obvious, as they can be set for regular time periods from memory.

The SQW freq is set to 1024 Hz and it's fixed. Or do you mean if I reconfigure the DS3231 by sending some I2C commands from time to time? Yes. I don't use alarms at all but I do GPS-RTC synchronization with DS3231. I've read many stories about fake DS3231 modules, and mine is probably a fake too as I bought it for 1.66$ delivered. The PPM is reasonable (within the datasheet documentation) and all the chips are marked with SN.

Your comment about a 1 sec pulse train (I assume you mean if you have to settle for that as a more reliable output) isn't clear.  The VDS1022 can be set for slow sweep speed and still capture fast transients by using peak detect rather than samples, as the ADC is still running at 100MS/s, despite only a lower number being used for the display.

You're right, I checked and I could capture a long pulse with the high sampling rate. My previous thinking was wrong.

Do you have a battery in your test circuit, as that should stop powerline issues.  If you are on breadboard, it could very well be glitches.  You don't want to be searching for non-issues but layout could also be causing pick-up or crosstalk on fast edges, moving things might help eliminate things that aren't what you expect to see.

The issues with 1 sec pulse happen as soon as I start changing the AGE offset register to match the SQW output with the GPS PPS ticks. Instead of the 1/1024 period, I'm getting rubbish in the [1/1024, 1.0] interval. I must note, however, that I get an occasional extra SQW tick even with no GPS module inserted (and hence no GPS-RTC sync), it just happens less frequently than with the GPS-RTC sync active.

• The power line is clean - measured with the scope at the DS3231 VCC pin.
  
• Tried with and without the internal battery that can be inserted into the DS3231 module. Same story
  
• I don't use breadboards. I designed and PCB-printed the board that has a 6P socket for a DS3231 module.
  
• I've read about PCB traces causing EMI issues to the RTC module. In my setup, the DS3231 is put in close proximity to the GPS module. This could be an issue though I doubt it.
  
• WiFi & Bluetooth are off.
  
• I don't have any other devices on the I2C bus.
  

So power supply seems not to be the issue.

I'm uploading two more screenshots. In both cases, the SQW was reset to a 1-sec pulse. The first plot shows the 32kHz output, and the second - VCC line.

[Bigwizman]

Hi dizcza,

My comment about the 1024 Hz was associated with I2C messages, as you assumed correctly, and my comment about alarms is because they can repeat every couple of minutes, which I thought could be what appeared to be random interruptions of the signal output.

I'm rusty on the DS3231 details but you are trying to keep it synchronised with the GPS.  Possible fake IC response is of course an unknown, so we can only hope but my own experience has been that if they don't comply, it is usually pretty obvious.  It is likely parts are from a source that was used by the original vendors in keeping costs down.  However, I'm slightly confused by using the AGE register to adjust synchronism, as my understanding was the DS3231 adjusts oscillator capacitance, to temperature correct the clock (32.768 Khz), altering the AGE pointer to the look-up table based on temperature.  Is there a reason AGE is altered, instead of leaving the DS3231 to adjust the clock aspects and simply uploading the correct time data from the GPS?  It seems that altering AGE could be injecting a larger clock disturbance, rather than the small changes that temperature could change over the minute or so it is regularly checked?  I think it is even possible to invoke a measurement?

I couldn't see a power supply trace but with a battery as well, I can't see a big problem, although check there aren't any big ground bounce voltages, it is just as important and not always obvious when a general probe ground point is used.  You are at least not on breadboard and are aware of other signals.

Are you now certain SQW switching to 1 Hz, coincides with an I2C message, as that is an obvious clue?  One item springs to mind, which is the addressing of the registers wraps around, so addressing outside the range will wrap back to some point within the correct address range.  If a mistake is being made there, you could be altering a register that was not the intended address.  You will be more aware of the exact nature of your code operation.  I think there are many ESP32 sketches associated with the DS3231, as well as GPS time adjustments and synchronisation.  I would only use GPS for super time accuracy, which most of the time isn't necessary but doing these things is a good educator!

Best regards.

Edit 1:  The images updated on my screen, so I've seen the Vcc trace now, nothing obvious, as you say.
Edit 2:  I refreshed my memory on the DS3231 datasheet and can see the AGE aspect.  It is an offset to the temperature adjustment, rather than my memory of it being the main pointer to the temperature tracking, so can see the logic of trying to keep the two ticks in sync, although maintaining it at zero error really requires an integrator and a little control theory for maintaining a stable feedback loop.  This thread has strayed rather a long way from the VDS1022 EXT trigger!

[dizcza]

The AGE register allows me to adjust the RTC clock very precisely: it can be synchronized with the GPS PPS signal within the (!) 1 us range. Reading time seconds from GPS UART data gives ~ 100 ms accuracy which is not enough for me. PPS syncing is well used for precise RTC clock calibration. To have an idea, here is an example project: https://github.com/liebman/esp32-gps-ntp.

The AGE is kept within the [-128, 127] interval prior to sending the I2C command.

I'm adjusting the AGE each second or so and yes, it loads heavily the RTC clock calibration routine. Especially when I set the AGE to the limits (either -128 or +127) to compensate for large offsets (100...400 us) from the PPS precise ticks (followed by setting the RTC time seconds from GPS UART data in case the offset is too large).

I haven't checked the I2C rails when SQW resets to 1 Hz.

It's hard to pinpoint the culprit because the issue could happen from a few seconds to a few hours. Fortunately, the scope allows me to capture & stop the trace for later inspection.

My application logic deals with occasional SQW freq resets and extra SQW ticks. It's just my curiosity that drives me to find out what's really happening.

One more idea that popped into my mind right now is that I'm using calibrated SQW ticks for precisely delayed sensor measurements at 1024 Hz. Each tick is processed in the ISR callback that notifies a high-priority task to actually read the sensor. The ISR function could potentially interrupt the I2C command I send to the DS3231 module like changing the AGE register. The ISR function and the reading sensor task are bound to a separate core of my ESP32 board. Still, this might somehow interfere. I'll need to check it by not doing anything on the second core.

I'll post more observations if I have any. In any case, thanks Bigwizman for helping out. Your suggestions make me feel that I'm on the right track because my thinking about possible reasons was similar to yours.

[2N3055]

If what you are using is DS3231M that one has MEMS oscillator with digital timing compensation.
Means they trim and skip pulses once in a while.
Check datasheet.

You need a DS3231 that is crystal oscillator based..

They are pin and register compatible and easy to mix up.

[dizcza]

If what you are using is DS3231M that one has MEMS oscillator with digital timing compensation.
Means they trim and skip pulses once in a while.
Check datasheet.

You need a DS3231 that is crystal oscillator based..

They are pin and register compatible and easy to mix up.

My DS3231 chips are marked SN, already checked.