Picoscope Hack

[_Wim_]

Some reverse engineering of the front end...

[markone]

Some reverse engineering of the front end...

Do you want to proceed with a Pspice simulation to estimate the impact of input resistor removal ?

If so you should gently unsolder all SMT capacitors and take precise value measurements ... 

[markone]

Some reverse engineering of the front end...

Dear WIM, I have a favor to ask you : could you gently check how the first three E2PROM pins are connected (A0,A1,A2) ?

If I look at Picoscope board PCB image I can spot a second unpopulated E2PROM footprint (also present in 2000A series) with readable address pins configuration but I wonder at which address is set the mounted E2PROM.

     

[jasonRF]

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 ...

I recommend looking at other vendors.  They do not seem to save the best stock for themselves. 

Jason

[markone]

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 ...

I recommend looking at other vendors.  They do not seem to save the best stock for themselves. 

Jason

Looked everywhere, beyond the attached list, it seems that 3203D, as well as other models with midrange prices, are vaporized or went in another dimension.

Only jewelery pieces are still available, it smells it's not matter of chip shortage  .

[jasonRF]

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 ...

I recommend looking at other vendors.  They do not seem to save the best stock for themselves. 

Jason

Looked everywhere, beyond the attached list, it seems that 3203D, as well as other models with midrange prices, are vaporized or went in another dimension.

Only jewelery pieces are still available, it smells it's not matter of chip shortage  .

Interesting.  I made my post after quickly seeing that Mouser has a couple in stock.  But I order from the US so Mouser is easy - I am not sure how useful it is from the rest of the planet. 

jason   

[markone]

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 ...

I recommend looking at other vendors.  They do not seem to save the best stock for themselves. 

Jason

Looked everywhere, beyond the attached list, it seems that 3203D, as well as other models with midrange prices, are vaporized or went in another dimension.

Only jewelery pieces are still available, it smells it's not matter of chip shortage  .

Interesting.  I made my post after quickly seeing that Mouser has a couple in stock.  But I order from the US so Mouser is easy - I am not sure how useful it is from the rest of the planet. 

jason

I order material from Mouser in regular basis, but some products are "inhibited" for EU region, 3203D is one of those.

[_Wim_]

Do you want to proceed with a Pspice simulation to estimate the impact of input resistor removal ?

If so you should gently unsolder all SMT capacitors and take precise value measurements ... 

No, that was not really the goal. It was more to understand the topology used...

[_Wim_]

Dear WIM, I have a favor to ask you : could you gently check how the first three E2PROM pins are connected (A0,A1,A2) ?

If I look at Picoscope board PCB image I can spot a second unpopulated E2PROM footprint (also present in 2000A series) with readable address pins configuration but I wonder at which address is set the mounted E2PROM.

Not sure why you would need this, but A0 to Vcc, and A1+A2 to Vss...

[markone]

Dear WIM, I have a favor to ask you : could you gently check how the first three E2PROM pins are connected (A0,A1,A2) ?

If I look at Picoscope board PCB image I can spot a second unpopulated E2PROM footprint (also present in 2000A series) with readable address pins configuration but I wonder at which address is set the mounted E2PROM.

Not sure why you would need this, but A0 to Vcc, and A1+A2 to Vss...

Thank you very much, what you report confirms that they used the standard FX2 address for E2PROM in generic device mode, and this is a good news 

Be patient, just another question ...    :

in your first post you said :

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"

Which table were you referring to ?

[_Wim_]

Which table were you referring to ?

The list with models attached as a txt-file in the first post

[markone]

Which table were you referring to ?

The list with models attached as a txt-file in the first post

Damn, age is taking the toll, I have to confess that I spent some time looking for it

Ok, now it's all crystal clear :

PS5442B = 94
PS5443A = 95
PS5443B = 96
PS5444A = 97
PS5444B = 98

I  finally understood where the offset value of 4 come from 

I wonder if the method you used to fix the checksum computation will work in every occasion, I have read the related algorithm description on Sigrok site and if I well understood the way it works it could be not the case.

Have you applied the subtraction several times at different address or it worked at first try ?

[_Wim_]

I wonder if the method you used to fix the checksum computation will work in every occasion, I have read the related algorithm description on Sigrok site and if I well understood the way it works it could be not the case.

Have you applied the subtraction several times at different address or it worked at first try ?

Yes, it might not work in some case where the byte sum already overflows in the bytes surrounding the model number. In my case it did however work at first try (I immediately saw a different scope type when I connected via USB), but I had to experiment a bit to find the correct model number.

Edit: see post below, should probably always work if my reasoning is correct

[_Wim_]

Yes, it might not work in some case where the byte sum already overflows in the bytes surrounding the model number.

Forgot to mention, I calculated the 14-bit sum for the signed bytes in Excel, and for the entire 256 bytes, I did not have any overflow occurring. The first overflow occurred only at byte "780".

As we are only playing around with the 32 first bytes than can contain a number between -127 & 128, is it not possible to overflow a 14-bit number as the sum can be max 4096, so I do think this trick should always work.

[voltsandjolts]

Thank you very much, what you report confirms that they used the standard FX2 address for E2PROM in generic device mode, and this is a good news 

Ahha, then fx2tool is your new friend

[markone]

Thank you very much, what you report confirms that they used the standard FX2 address for E2PROM in generic device mode, and this is a good news 

Ahha, then fx2tool is your new friend

It's my friend from a while, to be more precise Cypress USB Console + EZ-USB Interface (but I guess you already know).

It happens that maaany years ago I developed a 14bits ADC streamer based on commercial PATA HDD external case (Cypress CY7C68013 inside) in conjunction with a Labview application, this joke was able to push flawlessly 16MS/s x 16bits (32MB/s) toward a medium windows PC of the time, with some real time computation and disk logging.

Now you can understand why I smell BS if I read that the 2204A streaming mode is limited to 1MS/s due to the fact that the board has a buffer on only 8Kpts (inside the FPGA).

I had no FPGA and no buffer, but the system worked like a charm, so I would say that the 2204A sounds like a cripple fest.   

[markone]

Yes, it might not work in some case where the byte sum already overflows in the bytes surrounding the model number.

Forgot to mention, I calculated the 14-bit sum for the signed bytes in Excel, and for the entire 256 bytes, I did not have any overflow occurring. The first overflow occurred only at byte "780".

As we are only playing around with the 32 first bytes than can contain a number between -127 & 128, is it not possible to overflow a 14-bit number as the sum can be max 4096, so I do think this trick should always work.

Hi WIM,

this is exactly the point that I was referring to, in my case I have a total of 256 bytes, I would try too to compute the sum of signed bytes to understand IF and where it happens.

Just out of curiosity : how much you paid your Pico and which cost difference there is with your "upgraded" model ?

[tautech]

What was your key requirement again please markone ?
Maybe I can offer some screenshots from the scopes we have here.

[markone]

What was your key requirement again please markone ?
Maybe I can offer some screenshots from the scopes we have here.

Hi Tautech,

requirements are for an USB DSO with serial decoding capabilities and of course data recording.

Picoscope mid-range models are perfect for the purpose, problem is that they are not available in EU market and/or prices are a Little high for my taste (considered what's in the box).

The low end model, that is in my hand right now, is pretty useless for the purpose due to very limited internal buffer (but this was known) AND streaming mode limited to 100 ms/div setting, upward, at least with Picoscope 6/7 programs.

SDK should overcome this limitation but i'm not going to write an application for this right now.

Desktop scope with decoding capabilities are not tailored for this task, to give you an idea works a lot better an USB LA, but i need also at least one analog trace and Saleae is excluded from possible solution, for various reasons.

[tautech]

What was your key requirement again please markone ?
Maybe I can offer some screenshots from the scopes we have here.

Hi Tautech,

requirements are for an USB DSO with serial decoding capabilities and of course data recording.

Picoscope mid-range models are perfect for the purpose, problem is that they are not available in EU market and/or prices are a Little high for my taste (considered what's in the box).

The low end model, that is in my hand right now, is pretty useless for the purpose due to very limited internal buffer (but this was known) AND streaming mode limited to 100 ms/div setting, upward, at least with Picoscope 6/7 programs.

SDK should overcome this limitation but i'm not going to write an application for this right now.

Desktop scope with decoding capabilities are not tailored for this task, to give you an idea works a lot better an USB LA, but i need also at least one analog trace and Saleae is excluded from possible solution, for various reasons.

IIRC you required triggering on a specific bit, is that still the case ?
Been pretty busy getting newly arrived product out so only getting to touch base with you now.

[MrAl]

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.

Yes it's an interesting idea to use the LFSR as part of a checksum.  It generates a pseudo random number but with the same seed all the time the sequence will repeat, and thus you can always recreate the sequence if you know the seed.
Since the result of the LFSR is not very related to the input, it's interesting in that even with a string of 0's we'll get full register length outputs.  That kinda makes the sum more unique.  That's basically how CRC works too.
Basically CRC looks at the bytes and produces a result that is dependent on all the bytes in the sequence, and if any bytes change the chance of generating the same result is very small, so the result pseudo represents a unique values for a set of unique bytes.  I would think that would be better than any simple checksum although the calculation is more costly time wise.

[markone]

-snip
IIRC you required triggering on a specific bit, is that still the case ?
Been pretty busy getting newly arrived product out so only getting to touch base with you now.

Not on this specific case, i.e. Picoscope 6/7 do not support trigger on serial content, it's enough to react to a falling edge (first byte start bit) to let start the capture segment / serial decoding.

Of course a feature like that would be a nice addition.

[_Wim_]

Just out of curiosity : how much you paid your Pico and which cost difference there is with your "upgraded" model ?

I paid around 1.100€ ex. VAT, but I do not remember exactly what the highend model price was, but would estimate around 1700€? Off course, my upgraded version is not a "full" 5444B, I was mainly interest in the FFT extension (even if it had high frequency roll-off).

[markone]

Just out of curiosity : how much you paid your Pico and which cost difference there is with your "upgraded" model ?

I paid around 1.100€ ex. VAT, but I do not remember exactly what the highend model price was, but would estimate around 1700€? Off course, my upgraded version is not a "full" 5444B, I was mainly interest in the FFT extension (even if it had high frequency roll-off).

So you confirm that prices "went crazy" lately, right now this model cost much more, I guess you wouldn't have bought it at 1500-1600 plus taxes.

In my opinion current listing is no more justified, especially considering that now desktop DSOs are equipped with much more memory compared to the past and 12bits models are much cheaper.

In addition Picoscope 6 starts to be outdated, version 7 is far to be complete or stable and very few people are able (or have time) to develop custom application with SDK library.

[_Wim_]

So you confirm that prices "went crazy" lately, right now this model cost much more, I guess you wouldn't have bought it at 1500-1600 plus taxes.

I do not know. Back then (2017) there were not too many options for a 12bit scope, and the Picoscope was the (the only?) affordable option (and the fact that I already was a Picoscope user).

Today I would probably buy the 12 bit Siglent or Rigol.

As to the price I paid, there was also some price reduction as the follow up for the A/B series was coming to the market, so back then this model was also more expensive. If you compare Picoscope with Tek, Keysight and R&S, their pricing is still quite reasonable. But if you look at Siglent & Rigol, they cannot beat that kind of value for money, but they never could.

Their value has always been in the software, and this is in my opinion were lately they have not made much progress unfortunately. Picosoft 7 is indeed quite buggy, and development on Picoscope 6 has halted for >3 years (apart from the introduction of some new modules and bugfixes).

Still, it is my goto scope for analog work, and I certainly do not regret having bought it.