Picoscope Hack

[_Wim_]

Hi All,

After coming across the following webpage (https://sigrok.org/wiki/Pico_Technology_PicoScope_3206), it got me wondering if an upgrade to a higher bandwidth model would be possible by changing the  contents of the 24AA256 eeprom chip.

After some experimentation, I discovered that byte "0B" actually defines the device type AND that it can be altered!

My scope, a 5442B, originally had the hex value of "1C" for byte "0B". Using the attached table with device models, a 5444B is listed 4 places "higher" than the 5442B. So I incremented "1C" => "20" for byte "0B" AND lowered the serial number by 4 to keep the sum of the bytes equal (to maintain the checksum @byte "FE" and byte "FF"). My scope is now successfully detected as a 5444B and allows FFT up to 200MHz!  .Remark:ETS mode up to 10GS/s (instead of 2.5GS/s) does however not work, probably due to some hardware differences, but this is the least of my worries. 

To allow for easy experimentation, I installed 2 eeprom chips on a socket, and a switch to select between them. This way I can easily switch between the original and the "upgraded" version.

Off course no guarantee this works for all Picoscope models (but the fact that the same structure was used for both 3000-series and 5000-series is a good sign), and also the usual disclaimer that fooling around can brick your device, so do so at your own risk and certainly back-up the original eeprom contents first. 

[tv84]

Using the attached table with device models, a 5444B is listed 4 places "higher" than the 5442B. So I incremented "1C" => "20" for byte "0B"

  Nice inference!

[Nicole01]

Very good Job Congratulations 

[egonotto]

Hello,

do you now have 512 MS memory and 48 kS buffer space for AWG and really 200 MHz bandwidth?
ETS mode is 20GS/s

Best regards
egonotto

[_Wim_]

Hello,

do you now have 512 MS memory and 48 kS buffer space for AWG and really 200 MHz bandwidth?
ETS mode is 20GS/s

Best regards
egonotto

Will try to do some more detailed test next weekend. ETS is 10GS/s according to the datasheet I got together with my scope.

[egonotto]

Hello,

yes, the datasheet say for ETS 5 GS/s for PicoSope 5243A and 10 GS/s for PicoSope 5444B but in PicoScope 6 (and PicoScope 7) is 10 GS/s for PicoSope 5243A and 20 GS/s for PicoSope 5444B displayed.

Best regards
egonotto

[_Wim_]

Hello,

do you now have 512 MS memory and 48 kS buffer space for AWG and really 200 MHz bandwidth?
ETS mode is 20GS/s

Best regards
egonotto

Today I had some more time to further test this.

Bandwidth (tested with sweeping the CMU200 from 1 to 200MHz, 50ohm impedance adaptor installed on Pico scope input, FFT in peak hold mode)
- 8 bit mode: 5 db drop @200Mhz
- 12 bit mode: 7 db drop @200Mhz

Memory
- 8 bit mode: up to 100Msamples no issues, >100MSamles to 250Msamples is allowed by software, but channel overrange error is shown (even with no signal)
- 12 bit mode: up to 50Msamples no issues, > 50MSamples to 125MSamples is allowed by software, but spurious non existent signals are shown (but no overrange error)

Arb 48k
This seems to work without any issues at first glance.

ETS mode
ETS triggering freezes as soon as I drop below 1µs/div (should normally be 2.5Gs/s). In non-hacked "mode" I can go up to 5Gs/s without any issues.

Conclusion:
Definitely not a full 5444b, but a useful improvement if taking into account the limitations. Some hardware on the board is probably missing. I do not have a "real" 5444b to compare with, but I guess it will meet the datasheet spec. With the toggle switch I installed I can easily switch between "hacked" and original, so I am able to avoid some of the issues above.

[_Wim_]

Woohoo, the bandwidth has been fixed! Opening the front end shield, there was a 75ohm resistor in series with the input. I have change this to a zero ohm resistor, and 

Remark: I presume that the 1 dB variation is my signal generator itself...

[_Wim_]

This is the result in 12 bit mode. Sample rate is "only" 500MS/s, so 200MHz is pushing it. Still, a reasonable result that is certainly usable IMO.

For the other (probably hardware related issues) I will have a look later, now again some other priorities...

[voltsandjolts]

Nice!

Dave did a teardown of this scope a few years back, but didn't open up the front end cans.

youtu.be/TM7HGFOc74M?t=351

[_Wim_]

Nice!

Dave did a teardown of this scope a few years back, but didn't open up the front end cans.

youtu.be/TM7HGFOc74M?t=351

Thanks. I watched that one. It is also the version with the  protocol analyzer, and hence has a different board layout. It does however not have any unpopulated chips in contrast to mine, so those unpopulated sections will probably be the culprit for some of the remaining "issues".

[voltsandjolts]

Did you try figuring out the checksum algorithm at all? The sigrok page you pointed to hints at its workings:

There is a checksum, but is very weak and overly complicated. The last two bytes contain the number of iterations that have to be done to a 14 bit LFSR to get a value that equals the sum of the preceding data when interpreted as signed bytes. The weakness comes from their method of reducing the sum to 14 bits: During summing they reset the intermediate value to zero as soon as it uses more than 14 bits. As the bytes added are signed, this happens very often.

Not sure how they worked that out.
Don't think I've never seen LFSR used as a checksum method...ahh, well I suppose crc is an LFSR method.

There is another picotech device that interests me but the checksum there is a PITA. It might be the same as this one.

[_Wim_]

Did you try figuring out the checksum algorithm at all?

No, I did not. As the Sigrok paged showed bytes were summed and the checksum was just the position in the LFSR series that matches the sum, I just ensured the sum would not change by altering the serial number... I briefly thought about programming a generator in C#, but as my trick appeared to work, I did not invest any additional time in this.

Not sure how they worked that out.
Don't think I've never seen LFSR used as a checksum method...ahh, well I suppose crc is an LFSR method.

I have also no idea how they found that out, that would have been certainly far beyond my skills!

[_Wim_]

To fix the memory, I would need to change the memory chip which I consider too risky.

My board has a D9MNJ Micron Technologie (DDR3 SDRAM 1G-Bit 64Mx16), so that would mean max 128M samples @8bit, and I suspect that in 12bit mode they just half the amount of samples and leave those 4-bits unused. Remark: the 5444B from Dave's review had a D9SHD (256Mx16).

This explains why I start to see glitches going above 100MS, and no software hack will be able to fix this...

[_Wim_]

Rise time measurements (which confirms the 200Mhz bandwidth)

[egonotto]

Hello,

in PicoScope the entire memory is specified in bytes. Only in single trigger mode you can use it. Otherwise you only get half the memory because of double buffers. In 12 bit mode, a sample is 16 bit, so you have fewer samples.

The band width of my PicoScope 100MHz 5234A is greater than the band width of the PicoScope 200MHz 5444B

https://www.picotech.com/support/topic33731.html?&p=118661&hilit=egonotto#p118661

Best regards
egonotto

[_Wim_]

in PicoScope the entire memory is specified in bytes. Only in single trigger mode you can use it. Otherwise you only get half the memory because of double buffers. In 12 bit mode, a sample is 16 bit, so you have fewer samples.
&p=118661&hilit=egonotto#p118661[/url]

Thanks, that indeed confirms what I was seeing.

The band width of my PicoScope 100MHz 5234A is greater than the band width of the PicoScope 200MHz 5444B

I would not have expected that. Did you check if zero ohm series resistors were installed at the inputs on both scopes, or did they make a mistake with your 5444B installing incorrect resistors?  Did Pico ever reply to your question after you send them the PSDATA files?

[_Wim_]

Hi Egonotto, another question, do you also see spurs @multiples of 62.5Mhz in FFT mode (8-bit mode) in your 5444bB? This are most probably coming the interleaved sampling of the hmcad1520 ADC. In 12-bit mode these appear every 31.25MHz.

[_Wim_]

One more hardware difference between the low end model and the high ends models: a different clock is used. Not sure though if this is worthwhile to try and upgrade.

[_Wim_]

Hi Egonotto, another question, do you also see spurs @multiples of 62.5Mhz in FFT mode (8-bit mode) in your 5444bB? This are most probably coming the interleaved sampling of the hmcad1520 ADC. In 12-bit mode these appear every 31.25MHz.

These are the spurs I was talking about. Still >70db SFDR, so it meets its spec...

[egonotto]

Hello,

the bandwidth of my 5444B is fine at 200 MHz. But the bandwidth of my 100MHz 5234A is also 200MHz. Picotech didn't get back to me because of the bandwidth.
In direct comparison, the bandwidth of my 5444B is slightly smaller than the bandwidth of my 5234A.

My 5444B and 5234A also have spikes.

Best regards
egonotto

[_Wim_]

My 5444B and 5234A also have spikes.

Those look quite identical, so probably not possible to improve that easily.

[markone]

One more hardware difference between the low end model and the high ends models: a different clock is used. Not sure though if this is worthwhile to try and upgrade.

just to give you an idea of the huge cost gap between the low end  / high end series BOMs ...

+/- 50ppm : low cost oscillator, price under 1 euro in quantity of 100
+/-2ppm    : TCXO, unitary price around 2 euro in quantity of 100


In your place, provided that your warranty is dead, I would proceed with the mod.

[_Wim_]

just to give you an idea of the huge cost gap between the low end  / high end series BOMs ...

+/- 50ppm : low cost oscillator, price under 1 euro in quantity of 100
+/-2ppm    : TCXO, unitary price around 2 euro in quantity of 100


In your place, provided that your warranty is dead, I would proceed with the mod.

It is not the cost that would make it worthwhile or not, it is the trouble to find out all of the correct surrounding component values. Also the risk that if they are not correct, I make it worse instead of better. And the fact that the upgrade it will not make a whole lot of difference in my opinion. If I had a schematic of the 5444B, I would for sure do it however, as then it is easy and risk free. 

For example, the resistor I have changed above to increase the bandwidth, could still have other negative effects I am not aware of and was not the only thing (or not even the thing at all) that needs to be changed to increase the bandwidth. The more I think about it, the more I think those 75 ohm resistors should remain in place, and some other component(s) needs to be updated/removed to increase the bandwidth of the front end. But without schematics and without even a picture of a 5444B front end, that is hard to evaluate without a complete reverse engineering to the front end. 

[markone]

just to give you an idea of the huge cost gap between the low end  / high end series BOMs ...

+/- 50ppm : low cost oscillator, price under 1 euro in quantity of 100
+/-2ppm    : TCXO, unitary price around 2 euro in quantity of 100


In your place, provided that your warranty is dead, I would proceed with the mod.

It is not the cost that would make it worthwhile or not, it is the trouble to find out all of the correct surrounding component values. Also the risk that if they are not correct, I make it worse instead of better. And the fact that the upgrade it will not make a whole lot of difference in my opinion. If I had a schematic of the 5444B, I would for sure do it however, as then it is easy and risk free. 

For example, the resistor I have changed above to increase the bandwidth, could still have other negative effects I am not aware of and was not the only thing (or not even the thing at all) that needs to be changed to increase the bandwidth. The more I think about it, the more I think those 75 ohm resistors should remain in place, and some other component(s) needs to be updated/removed to increase the bandwidth of the front end. But without schematics and without even a picture of a 5444B front end, that is hard to evaluate without a complete reverse engineering to the front end.

I was referring solely to cost gap between high models / low models reference oscillators, it is so small that it sounds ridiculous that they do not  mount the +/- 2ppm part in all SKUs.

Now with few euros you will meet the time precision of top tiers 

In the mean time i was looking to Picotech webshop for one 3203D ... just to find out that chip shortage incidentally hits only "low cost" SKUs.

The cheapest model is an 3205D (2CH 100MHz 1GS/s) at whopping price of 979 euros plus taxes, that is the same cost of SDS2104X-Plus and I even paid less my Rigol HDO1074 ...

If you have an idea of what's inside the above mentioned desktop DSOs and what's inside a Picotech 3xxxD you start to wonder if Rigol & Siglent enjoy giving away their products or Picotech makes a monstrous margin.