Different behavior between 32 and 64 bit drivers

[JohnCell]

Hi forum users !

I wrote a C++ app that samples a signal that has +2.5V DC baseline and some AC pulses ( <400kHz ).
I'm using a 4424 Pico with ps4000.dll (either 32bits or 64bits, see below) under Windows 10.
The 4424 coupling is set to AC.

I first used the 32bits SDK files, and the +2.5V baseline of my signal was perfectly removed. Right from the very first sample.

Then, I recompiled my application to 64bits and I used the 64bits SDK files.
With the 64bits version, any sampled data start with some kind of capacitor falloff from the +2.5V baseline value when AC is set ?? This fall off from the +2.5V value roughly lasts 150ms.

I really don't in which direction to investigate ?

Any kind of help would be greatly appreciated !

Thanks,
John

[Martyn]

If you start with the 64bit version first and then switch to the 32bit does the issue swap around ?

It sounds like the second run through the scope is starting in DC mode until the application switches to AC.

Posting your code here, or sending it to support@picotech.com , will help us to debug your issue.

[JohnCell]

Hi Martyn,

Thanks for your prompt answer.

The application doesn't start in DC.
To be really sure, I've hard coded coupling mode.

I'm really talking of two different behavior of the *same piece of code* with either 32bits or 64bits compilation and SDK (ps4000.dll).

I've attached the sampled result (in AC coupling) of a constant signal that is just +2.5V ) = Cte.
Decay is clearly seen in 64bits.

The same signal sampled with the 32bit version and 32bits ps4000.dll gives a perfect result: zero from the first sample.

Code for channel setup is :

Code: Select all

// Setup Data channel A.
    CurrentStatus = ps4000SetChannel( Handle, PS4000_CHANNEL_A, int16_t( true ), int16_t( GLOBAL_PicoSignal_CouplingMode[0] ), (PS4000_RANGE)GLOBAL_PicoSignal_VoltageRange[0] );                       // Channel A activated, DC coupling, +/-5V range.
    if( CurrentStatus != PICO_OK )
      {
        ps4000CloseUnit( Handle );
        wxEndBusyCursor();
        wxMessageBox( "Can't set channel A.\n\nExiting.", "PicoScope error", wxOK |wxICON_ERROR );
        return( -1 );
       }
    CurrentStatus = ps4000SetDataBuffer( Handle, PS4000_CHANNEL_A, GLOBAL_PicoSignal_Data[0], GLOBAL_PicoSignal_SampleNumber );
    if( CurrentStatus != PICO_OK )
     {
        CurrentStatus = ps4000CloseUnit( Handle );
        wxEndBusyCursor();
        wxMessageBox( wxString( "Error allocating Channel A buffer :") << PicoGetErrorText( CurrentStatus ) << "\n\nExiting.", "PicoScope error", wxOK | wxICON_ERROR );
        return( -1 );
     }

[/size][/size][/i]



John

[Martyn]

Have you tried a hard code of

Code: Select all

int16_t( false )

in place of

Code: Select all

int16_t( GLOBAL_PicoSignal_CouplingMode[0]

in the SetChannel call.

[JohnCell]

OK, I've just tried what you suggested : no change.

One could have expected this.
Because when the input signal to be sampled is a +2.5Vconstant one, there are only two possibilities:
- DC coupling and you get all samples @ +2.5V.
- AC coupling and you get all samples @ 0.0 V.
There shouldn't be any transient decay in either mode.

I do stress this transient decay (with AC coupling) only happens with 64bits driver (and app).
The same C++ code works like a charm (no transient decay) with 32bits driver and app.

John

[Martyn]

The decay would occur if there is a switch from DC to AC, as if the scope starts sampling in one mode then switches to another. There may be something subtle in your code, such as data types or timings, which is causing the issue in the 64 bit driver. The code base for both drivers is the same, so the same situation as with your code.

I will try to set up a simple test when I am back in the office tomorrow, but I may need to see you complete code flow if I can't reproduce the issue.

[JohnCell]

Hi Martyn !

>>The decay would occur if there is a switch from DC to AC...
OK, understood !

As a work around, I put a 500ms delay after setting channels and trigger and before calling ps4000RunStreaming: it works !

It's no problem for me if you want to take a look at the code.
Just let me know.

Thanks for you help.
John