EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: _Wim_ on November 20, 2022, 08:52:49 pm
-
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! ;D .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.
-
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"
:clap: Nice inference!
-
Very good Job Congratulations :-+
-
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
-
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.
-
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
-
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.
-
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...
-
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...
-
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 (http://youtu.be/TM7HGFOc74M?t=351)
-
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 (http://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".
-
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.
-
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!
-
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...
-
Rise time measurements (which confirms the 200Mhz bandwidth)
-
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 (https://www.picotech.com/support/topic33731.html?&p=118661&hilit=egonotto#p118661)
Best regards
egonotto
-
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?
-
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.
-
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.
-
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...
-
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
-
My 5444B and 5234A also have spikes.
Those look quite identical, so probably not possible to improve that easily.
-
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 :D ...
+/- 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.
-
just to give you an idea of the huge cost gap between the low end / high end series BOMs :D ...
+/- 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.
-
just to give you an idea of the huge cost gap between the low end / high end series BOMs :D ...
+/- 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.
-
Some reverse engineering of the front end...
-
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 ... :D
-
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.
-
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
-
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 ;).
-
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
-
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.
-
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 ... :D
No, that was not really the goal. It was more to understand the topology used...
-
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...
-
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 ?
-
Which table were you referring to ?
The list with models attached as a txt-file in the first post
-
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 :palm:
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 :D
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 ?
-
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
-
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.
-
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 (https://www.eevblog.com/forum/testgear/saleae-clone-24mhz-8-channel-la-looses-its-brains/msg4050142/#msg4050142)is your new friend >:D
-
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 (https://www.eevblog.com/forum/testgear/saleae-clone-24mhz-8-channel-la-looses-its-brains/msg4050142/#msg4050142)is your new friend >:D
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.
-
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 ?
-
What was your key requirement again please markone ?
Maybe I can offer some screenshots from the scopes we have here.
-
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.
-
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.
-
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.
-
-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.
-
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).
-
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.
-
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.
-
This is the schematic front end until first amplifier
EDIT: added resistor at offset input, as markone was correct, this caused confusion
-
My 3406D was 2100€ few years ago when I bought it and worth every penny...
My 12000€+ Keysight MSOX3104T has 4MPts sample memory.
3406D MSO has 500Mpts...
I bought it for decoding and for high end features in software, SDK and FRA...
I also have 16bit Pico 4262 that is absolutely unique. At 1000€ it has specs no other scope has at any price..
And I also have 4824A that is 20MHz 12 bit 8 channel scope.. It is not 200€, but go find 8ch 12bit scope that is not 10x more. etc etc...
Fact is, my two 12 bit Siglents mostly replaced MSOX3104T in use, but not Picoscopes...
When it's time for Picoscope, it's time for it.
I agree that their pricing is not following the same logic as some other manufacturers. But it is special product in many ways..
-
This is the schematic front end until first amplifier
I guess there is a resistor in between offset setting and opamp negative input.
10pF and 7pF capacitors were actually measured ?
-
I guess there is a resistor in between offset setting and opamp negative input.
Yes, I did not further draw that part => Edit => now updated in the schematic above
10pF and 7pF capacitors were actually measured ?
They were measured in circuit with my HP 4276A, so that will not be very accurate. For most caps I could not even get a reading, but for the onces I did, take them certainly with a grain of salt (I did not fance desoldering them all risking that one "jumps" away or is damaged in the process...)
-
My 3406D was 2100€ few years ago when I bought it and worth every penny...
My 12000€+ Keysight MSOX3104T has 4MPts sample memory.
3406D MSO has 500Mpts...
I bought it for decoding and for high end features in software, SDK and FRA...
I also have 16bit Pico 4262 that is absolutely unique. At 1000€ it has specs no other scope has at any price..
And I also have 4824A that is 20MHz 12 bit 8 channel scope.. It is not 200€, but go find 8ch 12bit scope that is not 10x more. etc etc...
Fact is, my two 12 bit Siglents mostly replaced MSOX3104T in use, but not Picoscopes...
When it's time for Picoscope, it's time for it.
All the models that you listed are quite peculiar/unique, this does not apply to ordinary models, especially 2000 series, that i would consider overpriced for USB2.0 devices.
I was tempted for a 3000 series, but sweet spot SKUs are not available at all.
I agree that their pricing is not following the same logic as some other manufacturers. But it is special product in many ways..
That's my point, they are increasing prices also for old models when "some other manufacturers" are improving day by day specs and listing cost and often make sales campaign.
-
I guess there is a resistor in between offset setting and opamp negative input.
Yes, I did not further draw that part => Edit => now updated in the schematic above
10pF and 7pF capacitors were actually measured ?
They were measured in circuit with my HP 4276A, so that will not be very accurate. For most caps I could not even get a reading, but for the onces I did, take them certainly with a grain of salt (I did not fance desoldering them all risking that one "jumps" away or is damaged in the process...)
One method would be desolder resistors placed in series, much less fragile and marked and easy to replace, but it's not worth doing it if you are not interested to perform an AC simulation.
-
Hello,
I paid about 950 € for the PS 5243A in 2015 and about 1972 € for the PS 5444B in 2017.
Best regards
egonotto
-
Hello,
I paid about 950 € for the PS 5243A in 2015 and about 1972 € for the PS 5444B in 2017.
Best regards
egonotto
5444B seems no more available, there is 5444D at 3700 euros ...:o (or even more, depending on the seller)
-
All the models that you listed are quite peculiar/unique, this does not apply to ordinary models, especially 2000 series, that i would consider overpriced for USB2.0 devices.
Sure, they are expensive compared to budget benchtop scopes made by Rigol/Siglent/Instek/etc. But early this year I was in the market for a USB scope upgrade where I wanted 2 channels and at least 100 MHz bandwidth, along with deep memory, large FFTs, serial decoding and either high-res mode or digital low-pass filtering. I did not find any viable options besides Picoscope. Sure, you can find cheaper USB scopes with reasonable hardware specs manufactured by Owon or DreamSourceLab or others, but you just do not get the rest of the capabilities. My budget was too low for a 2208B (or even a 2207B), so I shopped ebay for a handful of months until I found something I could afford. I would have been happy with a 2000 or 3000-series, but the first good option I found was a 5244B that I picked up for $450 US.
I think a lot of the Picoscope cost is due to design and manufacturing in the UK (at least both of mine are made in the UK), relatively low sales volumes, and the superior software/firmware. If a company like Owon decided to be serious about their software, they could give Pico enough competition to force prices down, but this doesn't seem likely to happen any time soon.
jason
-
Has anyone tried to upgrade the waveform memory (DDR2 SO-DIMM) in a PicoScope 6000 series (mine is a 6403B with 512 MB common memory; the 500 MHz model can have up to 2 GB common memory) and if so, does it require a code and/or different control software to enable the extra memory?
If the memory can be upgraded, is it also possible to upgrade beyond 2 GB using a special code or different control software if necessary?
From what I know, the PicoScope (with removable memory) uses SO-DIMM memory modules and there are no registered SO-DIMM modules out there (registered modules are typically required in workstations and servers with more than four DIMM slots and therefore, there was no need for registered SO-DIMM modules) - the pictures at https://www.eevblog.com/forum/testgear/picoscope-pico6402a-6404d-teardown/ (https://www.eevblog.com/forum/testgear/picoscope-pico6402a-6404d-teardown/) show a Texas Instruments IC on the SO-DIMM which is most likely used for signal termination to prevent ringing at very high speed.
-
All the models that you listed are quite peculiar/unique, this does not apply to ordinary models, especially 2000 series, that i would consider overpriced for USB2.0 devices.
Sure, they are expensive compared to budget benchtop scopes made by Rigol/Siglent/Instek/etc. But early this year I was in the market for a USB scope upgrade where I wanted 2 channels and at least 100 MHz bandwidth, along with deep memory, large FFTs, serial decoding and either high-res mode or digital low-pass filtering. I did not find any viable options besides Picoscope. Sure, you can find cheaper USB scopes with reasonable hardware specs manufactured by Owon or DreamSourceLab or others, but you just do not get the rest of the capabilities. My budget was too low for a 2208B (or even a 2207B), so I shopped ebay for a handful of months until I found something I could afford. I would have been happy with a 2000 or 3000-series, but the first good option I found was a 5244B that I picked up for $450 US.
I think a lot of the Picoscope cost is due to design and manufacturing in the UK (at least both of mine are made in the UK), relatively low sales volumes, and the superior software/firmware. If a company like Owon decided to be serious about their software, they could give Pico enough competition to force prices down, but this doesn't seem likely to happen any time soon.
jason
5244B at 450 USD seems quite a bargain, I guess that you would never have bought it at full price.
I agree to pay a plus for a professional SW support but to be honest Picoscope 6 nowadays sounds quite outdated, at that price mechanisms like serial protocol trigger and performance streaming mode should be a standard feature, on the other hand brands like Owon & Hantek, that sometimes provide decent HW for the money, are much worse, often at a level that renders their products almost useless for serious job. I do not mention Picoscope 7 because it's still almost work in progress.
Years ago, with lower prices and less competition from desktop DSO's market, Picoscope listing was much more justified, now you have to have quite peculiar/niche needing to find an acceptable balance money / features.
The fact that Picoscopes are assembled by third parts in UK it's a factor that increase cost but not at the that level, at least for that level of quantity.
You are right, if only Owon ... but i fear that sadly we never see that.
-
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 :-+ :-+ :-+
To further evaluate the frequency response at all ranges, I made the following test setup:
BG7TBL Noise source => DC-block => Stepped attenuator => 50-ohm input adaptor => Picoscope input
This gave me a relative smooth noise spectrum that I could attenuate, to test the response on all ranges. To make the comparison easier, all plots where normalized to the +-20V range (with zero ohm resistor mod). Goal was to compare the frequency response with different attenuator settings in the scope to ensure the zero ohm mod worked correctly with different attenuator settings.
The same test was performed with the unmodified input (with 75 ohm series resistor). Conclusion: both unmodified and modified had +-2dB variation over all the ranges.
-
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 :-+ :-+ :-+
To further evaluate the frequency response at all ranges, I made the following test setup:
BG7TBL Noise source => DC-block => Stepped attenuator => 50-ohm input adaptor => Picoscope input
This gave me a relative smooth noise spectrum that I could attenuate, to test the response on all ranges. To make the comparison easier, all plots where normalized to the +-20V range (with zero ohm resistor mod). Goal was to compare the frequency response with different attenuator settings in the scope to ensure the zero ohm mod worked correctly with different attenuator settings.
The same test was performed with the unmodified input (with 75 ohm series resistor). Conclusion: both unmodified and modified had +-2dB variation over all the ranges.
Interesting, I would try with some other values for input resistor because with zero It would seem that aliasing could be a problem.
-
BG7TBL Noise source => DC-block => Stepped attenuator => CMU200 vs
BG7TBL Noise source => DC-block => Stepped attenuator => 50-ohm input adaptor => Picoscope input
As the same "drop" between 60Mhz and 160Mhz is seen as when I sweeped the CMU200 generator to the picoscope input (https://www.eevblog.com/forum/testgear/picoscope-hack/msg4545359/#msg4545359 (https://www.eevblog.com/forum/testgear/picoscope-hack/msg4545359/#msg4545359)), I do start to believe the Pico is a little low between 60Mhz and 160Mhz...
-
Interesting, I would try with some other values for input resistor because with zero It would seem that aliasing could be a problem.
Might be worth a try, but I would have expected to see those aliasing effects in the spectrums measured above.
-
Interesting, I would try with some other values for input resistor because with zero It would seem that aliasing could be a problem.
Might be worth a try, but I would have expected to see those aliasing effects in the spectrums measured above.
Do you have a sinusoidal signal generator capable to go over 200 MHz ?
-
Do you have a sinusoidal signal generator capable to go over 200 MHz ?
Yes, the CMU200 (can go to 2.7GHz), and you are correct, aliasing does occur for input signals > 300 Mhz (just did a quick test)
-
aliasing does occur for input signals > 300 Mhz (just did a quick test)
But even with the original 75 Ohm resistor, the aliased signal is only +-13dB lower (so a -20dBm 301Mhz Signal is aliased to 199Mhz 13dB lower as the input). Test ran in 12bit mode => 500MS/s
With the zero ohm resistor in place, we are -3dB only...
-
aliasing does occur for input signals > 300 Mhz (just did a quick test)
But even with the original 75 Ohm resistor, the aliased signal is only +-13dB lower (so a -20dBm 301Mhz Signal is aliased to 199Mhz 13dB lower as the input). Test ran in 12bit mode => 500MS/s
With the zero ohm resistor in place, we are -3dB only...
@egonotto, if you have RF generator that can send a 301MHz signal , would you be willing to run this also on your 5444B? I would like to know if this is an artifact from the "upgrade" or not. It could be that the LMH6574 is used to select between 4 anti-aliasing filters, and that the component values differ between the 5442B and the 5444B...
-
Hello,
here are 3 pictures with sine with 50 Ohm termination 100 MHz 301 MHz and 320 MHz
Best regards
egonotto
-
Hello,
here are 3 pictures with sine with 50 Ohm termination 100 MHz 301 MHz and 320 MHz
Best regards
egonotto
Excellent! Thanks for confirming, this saves me from trying to fix something that would not have been fixable. :phew:
-
A bit off topic, but not completely...
Because the BG7TBL noise source was very spiky between 0 and 2MHz, I had always been using a low cost DC block to act as a high pass filter. Today I made a quick and dirty filter board to get completely rid of these spikes (5th order filter), and also flatten the response up to 200Mhz.
After some experimentation, I achieved a flatness of < 2dBm between 10Mhz and 200MHz.
For reference, I attached also the spectrum measured up to 2000MHz measured with my CMU200, but the high frequency spectrum is not changed.
-
I can verify that there is at least one Picoscope that doesn't follow this hacking recipe. :-DD
I have a 2204a I purchased in 2016. The hardware version is 17. Anyway, increasing byte 0B by 1 and decreasing byte 1B by 1 did not do the trick. I have tried a bunch of other options as well, but so far all of the trials have resulted in a device that the picoscope software does not recognize.
Edit:forgot to say that i am trying to turn it into a 2205a, which has identical hardware.
The eeprom on my 2204a is definitely different than the one discussed on the sigroc page. For example, B7-D9 and F8-FD are all non-zero. I have of course mucked with some of these bytes as well - especially F8-FD that look less like cal data than some of the other areas.
I am very inexperienced when it comes to this kind of stuff, so any suggestions you-all might have would be helpful. For the trial and error approach I have been using so far, it might be time to write a python script to automate it more.
In any case, it has been fun to play with this.
cheers,
jason
-
I can verify that there is at least one Picoscope that doesn't follow this hacking recipe. :-DD
I have a 2204a I purchased in 2016. The hardware version is 17. Anyway, increasing byte 0B by 1 and decreasing byte 1B by 1 did not do the trick. I have tried a bunch of other options as well, but so far all of the trials have resulted in a device that the picoscope software does not recognize.
Edit:forgot to say that i am trying to turn it into a 2205a, which has identical hardware.
The eeprom on my 2204a is definitely different than the one discussed on the sigroc page. For example, B7-D9 and F8-FD are all non-zero. I have of course mucked with some of these bytes as well - especially F8-FD that look less like cal data than some of the other areas.
I am very inexperienced when it comes to this kind of stuff, so any suggestions you-all might have would be helpful. For the trial and error approach I have been using so far, it might be time to write a python script to automate it more.
In any case, it has been fun to play with this.
cheers,
jason
Can you post the original bin file here? Do you have somewhere a byte with the value "77" in the original binary?
-
I can verify that there is at least one Picoscope that doesn't follow this hacking recipe. :-DD
I have a 2204a I purchased in 2016. The hardware version is 17. Anyway, increasing byte 0B by 1 and decreasing byte 1B by 1 did not do the trick. I have tried a bunch of other options as well, but so far all of the trials have resulted in a device that the picoscope software does not recognize.
Edit:forgot to say that i am trying to turn it into a 2205a, which has identical hardware.
The eeprom on my 2204a is definitely different than the one discussed on the sigroc page. For example, B7-D9 and F8-FD are all non-zero. I have of course mucked with some of these bytes as well - especially F8-FD that look less like cal data than some of the other areas.
I am very inexperienced when it comes to this kind of stuff, so any suggestions you-all might have would be helpful. For the trial and error approach I have been using so far, it might be time to write a python script to automate it more.
In any case, it has been fun to play with this.
cheers,
jason
Can you post the original bin file here? Do you have somewhere a byte with the value "77" in the original binary?
Hi _Wim_,
Good question! I did notice that byte F8 is 77 so is the nominal device type 119, and have played with increasing it by one and then decreasing the neighboring bytes (one at a time, of course) by one, but all to no avail. I have attached a file with the eeprom dump I made using an arduino. I wrote the file to include both hex and dec values because I don't think so well in hex.
Edit: and if you want the file in a different format let me know. I used a python script to talk to the arduino and dump this file, so is easy to do it again in a different format.
Thanks,
jason
-
I can verify that there is at least one Picoscope that doesn't follow this hacking recipe. :-DD
I have a 2204a I purchased in 2016. The hardware version is 17. Anyway, increasing byte 0B by 1 and decreasing byte 1B by 1 did not do the trick. I have tried a bunch of other options as well, but so far all of the trials have resulted in a device that the picoscope software does not recognize.
Edit:forgot to say that i am trying to turn it into a 2205a, which has identical hardware.
The eeprom on my 2204a is definitely different than the one discussed on the sigroc page. For example, B7-D9 and F8-FD are all non-zero. I have of course mucked with some of these bytes as well - especially F8-FD that look less like cal data than some of the other areas.
I am very inexperienced when it comes to this kind of stuff, so any suggestions you-all might have would be helpful. For the trial and error approach I have been using so far, it might be time to write a python script to automate it more.
In any case, it has been fun to play with this.
cheers,
jason
We meet here as well! :D :D
I am still curious how this adventure ended up and if/how it works with the 2000 series? :) 8)
-
We meet here as well! :D :D
I am still curious how this adventure ended up and if/how it works with the 2000 series? :) 8)
I was never able to get the unit upgraded, although there is at least one person here who did change a 2204a to a 2205a. My 2204a isn’t used very much anymore so it really doesn’t matter to me. It was just fun to poke at. I would brute force it with a python script using an arduino and the pico api (and I even started to), but everytime you test to see if the api recognizes the scope you hear relays clicking. After a hundred unsuccessful attempts I killed my script since didn’t want to wear out the relays for no good reason.
Jason
-
I can verify that there is at least one Picoscope that doesn't follow this hacking recipe. :-DD
I have a 2204a I purchased in 2016. The hardware version is 17. Anyway, increasing byte 0B by 1 and decreasing byte 1B by 1 did not do the trick. I have tried a bunch of other options as well, but so far all of the trials have resulted in a device that the picoscope software does not recognize.
Edit:forgot to say that i am trying to turn it into a 2205a, which has identical hardware.
The eeprom on my 2204a is definitely different than the one discussed on the sigroc page. For example, B7-D9 and F8-FD are all non-zero. I have of course mucked with some of these bytes as well - especially F8-FD that look less like cal data than some of the other areas.
Had no problems to hack 2204A (HW Version 17, cal 2023-04-17) to 2205A using fx2tool as described in the Saleae thread (https://www.eevblog.com/forum/testgear/saleae-clone-24mhz-8-channel-la-looses-its-brains/msg4050142/#msg4050142).
Save to eeprom.hex:
fx2tool -B -d 0CE9:1007 read_eeprom -W 1 0 256 -f eeprom.hex
Changed byte 0B from 1A to 1B and reduced the serial by one (bytes 13-1B) and used HEX file checksum online calculator (https://www.fischl.de/hex_checksum_calculator/) for correcting checksum at the line ends.
Upload from eeprom_hack.hex:
fx2tool -B -d 0CE9:1007 write_eeprom -W 1 -f eeprom_hack.hex
Replug the scope, otherwise it will not be recognized.
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.
The limit with current SDK is 150ns/6.67MSPS for continuous fast streaming for one CH, but sometimes it drops a couple of samples.
-
I can verify that there is at least one Picoscope that doesn't follow this hacking recipe. :-DD
I have a 2204a I purchased in 2016. The hardware version is 17. Anyway, increasing byte 0B by 1 and decreasing byte 1B by 1 did not do the trick. I have tried a bunch of other options as well, but so far all of the trials have resulted in a device that the picoscope software does not recognize.
Edit:forgot to say that i am trying to turn it into a 2205a, which has identical hardware.
The eeprom on my 2204a is definitely different than the one discussed on the sigroc page. For example, B7-D9 and F8-FD are all non-zero. I have of course mucked with some of these bytes as well - especially F8-FD that look less like cal data than some of the other areas.
Had no problems to hack 2204A (HW Version 17, cal 2023-04-17) to 2205A using fx2tool as described in the Saleae thread (https://www.eevblog.com/forum/testgear/saleae-clone-24mhz-8-channel-la-looses-its-brains/msg4050142/#msg4050142).
Save to eeprom.hex:
fx2tool -B -d 0CE9:1007 read_eeprom -W 1 0 256 -f eeprom.hex
Changed byte 0B from 1A to 1B and reduced the serial by one (bytes 13-1B) and used HEX file checksum online calculator (https://www.fischl.de/hex_checksum_calculator/) for correcting checksum at the line ends.
Upload from eeprom_hack.hex:
fx2tool -B -d 0CE9:1007 write_eeprom -W 1 -f eeprom_hack.hex
Replug the scope, otherwise it will not be recognized.
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.
The limit with current SDK is 150ns/6.67MSPS for continuous fast streaming for one CH, but sometimes it drops a couple of samples.
So I assume the 2204A can only be "upgraded" to the 2205A ?
I still really like the picoscope software, so much better than my physical scope.
It's just that they are so pricey :(
-
at the price we paid a 3406d i would have bought an huge siglent model loll
lost my arms and legs loll
picoscope newest sw need some improvements, but getting there
-
Had no problems to hack 2204A (HW Version 17, cal 2023-04-17) to 2205A
--snip--
Thanks for the clear instructions. Worked a treat for me too!
[attachimg=1]
-
I’d guess that Rigol and Siglent have a much larger market share and likely get better component pricing as a result. Their manufacturing costs are probably also lower. That said, they likely are able to manage lower profit margins on much of their product line as a result.
Another consideration is that Pico needs to sustain the software development that makes their products so valuable. A hardware BOM cost comparison probably doesn’t provide the whole picture.
I think that Pico’s software environment would suit my scope needs better than stand alone desktop products - it seems very handy for observing and finding issues with longer acquisitions. Too bad they are out of my financial budget.
-
Had no problems to hack 2204A (HW Version 17, cal 2023-04-17) to 2205A
--snip--
Thanks for the clear instructions. Worked a treat for me too!
(Attachment Link)
My serial is ending with zero J****/**30 , if I change it to J****/**29 - hack does not work, if I decrease last digit in number J****/**30 by 1 so it will be last digit hex 29 so not a number anymore ( 0 is hex 30).
Is there any way for such case?
-
Hi all,
I very new to this side of tech. I think I have libusb and fx2tool setup properly on my macbook. When I connect my picoscope 2405a, I see in my system information that it has pid 1016. Now when I sent the command:
fx2tool -B -d 0CE9:1016 read_eeprom -W 1 0 256 -f eeprom.hex
I get the response:
Command not acknowledged (wrong address width?)
fx2tool -B -d 0CE9:1016 read_eeprom -W 2 0 256 -f eeprom.hex
this works and writes the file.
After a bit of puzzeling and reading through all the posts again I figured out which numbers to change (I used a straight text editor) and uploaded the new file with:
fx2tool -B -d 0CE9:1016 write_eeprom -W 2 -f eeprom_hack32.hex
Did a readback and found the new numbers in place.
Next I started picoscope 7 and it finds a 2406B, with the serial 1 lower than before, but it also shows a red X and says failed.
So I hope that the great folks on this forum can nudge me in the right direction. I just want to see what is possible. Even upgrading it 1 step from 25 to 50 Mhz would be welcome.
At least loading the original backup back, did restore the scope to the factory settings and it works in picoscope 7.
-
We do know that some of the 2204A models can be upgraded to the 2205A, however I do believe that 2406B model is a totaly different species (different size and hardware) so no upgrade will be possible ...
-
We do know that some of the 2204A models can be upgraded to the 2205A, however I do believe that 2406B model is a totaly different species (different size and hardware) so no upgrade will be possible ...
Con confirm. I have a 2205 and 2206 and they are completely different despite the external case looking similar.
-
Glad to hear that it is hardware related. It at least means that I most likely understood how it should be done, it just isn’t possible. The upside is I learned a new skill ;)
I bought the cheapest 4 channel basically for myself and have at the moment no specific use for higher bandwidth. It is mainly to see if it works better than my old tiepie and labnation. That last one had some serious potential, but the company never continued development of the software other than bugfixes. The tiepie I got like 15 years ago at work, but I believe it is only 2 channels and 5 or 10Mhz and is now a bit outdated for the newer hardware we use. Since it still works it is a bit hard to convince the boss that we need something new. In the latest hardware we delivered we use encoders with 4 signals, hence the 4 channels. I had one encoder that turned out to be wonky, but to prove that I had to make many measurements by combining 2 channels at a time. With 4 channels I can check this in 1 go. If I can order a new one for work I’ll ask for a 50Mhz, 4 channel (that would be a B-version).
-
Had no problems to hack 2204A (HW Version 17, cal 2023-04-17) to 2205A
--snip--
Thanks for the clear instructions. Worked a treat for me too!
(Attachment Link)
My serial is ending with zero J****/**30 , if I change it to J****/**29 - hack does not work, if I decrease last digit in number J****/**30 by 1 so it will be last digit hex 29 so not a number anymore ( 0 is hex 30).
Is there any way for such case?
No need to change the last digit, just change one digit of the SN.