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"
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
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)
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.
Did you try figuring out the checksum algorithm at all?
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.
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]
The band width of my PicoScope 100MHz 5234A is greater than the band width of the PicoScope 200MHz 5444B
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.
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.
Some reverse engineering of the front end...
Some reverse engineering of the front end...
I recommend looking at other vendors. They do not seem to save the best stock for themselves.
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.
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 ...
Jason
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.I recommend looking at other vendors. They do not seem to save the best stock for themselves.
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 ...
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.I recommend looking at other vendors. They do not seem to save the best stock for themselves.
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 ...
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 ;).
jason
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
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.
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...
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
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.
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 ;)
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
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.
What was your key requirement again please markone ?
Maybe I can offer some screenshots from the scopes we have here.
IIRC you required triggering on a specific bit, is that still the case ?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.
Did you try figuring out the checksum algorithm at all? The sigrok page you pointed to hints at its workings:QuoteThere 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.
-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.
Just out of curiosity : how much you paid your Pico and which cost difference there is with your "upgraded" model ?
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.
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 ?
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..
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 above10pF 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...)
Hello,5444B seems no more available, there is 5444D at 3700 euros ...:o (or even more, depending on the seller)
I paid about 950 € for the PS 5243A in 2015 and about 1972 € for the PS 5444B in 2017.
Best regards
egonotto
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.
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.
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 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
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 :-+ :-+ :-+
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.
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 ?
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...
Hello,
here are 3 pictures with sine with 50 Ohm termination 100 MHz 301 MHz and 320 MHz
Best regards
egonotto
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
Hi _Wim_,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. :-DDWe meet here as well! :D :D
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 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.
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 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.
fx2tool -B -d 0CE9:1007 read_eeprom -W 1 0 256 -f eeprom.hexfx2tool -B -d 0CE9:1007 write_eeprom -W 1 -f eeprom_hack.hex
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.
So I assume the 2204A can only be "upgraded" to the 2205A ?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:Code: [Select]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:Code: [Select]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.
Had no problems to hack 2204A (HW Version 17, cal 2023-04-17) to 2205AThanks for the clear instructions. Worked a treat for me too!
--snip--
Had no problems to hack 2204A (HW Version 17, cal 2023-04-17) to 2205AThanks for the clear instructions. Worked a treat for me too!
--snip--
(Attachment Link)
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.
Had no problems to hack 2204A (HW Version 17, cal 2023-04-17) to 2205AThanks for the clear instructions. Worked a treat for me too!
--snip--
(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?