I can verify that there is at least one Picoscope that doesn't follow this hacking recipe. 
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.
Save to eeprom.hex:
fx2tool -B -d 0CE9:1007 read_eeprom -W 1 0 256 -f eeprom.hexChanged byte 0B from 1A to 1B and reduced the serial by one (bytes 13-1B) and used
HEX file checksum online 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.hexReplug 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.
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.
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 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!
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.
Here is a correct table with PicoScope model numbers (visible in the EEPROM byte at offset 0x0B).
Here is a correct table with PicoScope model numbers (visible in the EEPROM byte at offset 0x0B).
Fantastic! I will update the first post and reference to this one.
Types of EEPROM checksums used (decided by byte at offset 0x12).
@_Wim_What kind of checksum type did your scope 5442B had at offset 0x12, was it 0x00 or 0x01?
Thanks
Extended checksum is seeded by the unique ID in the FX2 microcontroller on the picoscope.
However, it's relatively easy to recover the seed if you have the original eeprom for your device.
I've attached a python script that can do that.
First recover the seed from the original eeprom:
$ python3 eeprom_checksum.py 2204a.hex --recover-seed
recovered seed:
0x98511234
mode: extended
seed: 0x98511234
stored: 0x2BAD4AFCA3B4ABCD
calculated: 0x2BAD4AFCA3B4ABCD
Make a copy (let's call it 2205a), and change 2204a -> 2205a by changing the byte at offset 0xb 0x1a -> 0x1b .
Then update the checksum using the seed reported for the original eeprom.
$ python3 eeprom_checksum.py 2205a.hex --input-format hex --seed 0x98511234 --output 2205a.hex --output-format hex && python3 eeprom_checksum.py 2205a.hex --input-format hex --seed 0x98511234 --verify
mode: extended
seed: 0x98511234
stored: 0x2BAD4AFCA3B4ABCD
calculated: 0x56338CE9A66B170B
wrote: 2205a.hex (hex)
mode: extended
seed: 0x98511234
stored: 0x56338CE9A66B170B
calculated: 0x56338CE9A66B170B
verify: OK
Then you can program the 2205a back into the picoscope and it will recognize the device as 2205a.
it's relatively easy to recover the seed if you have the original eeprom for your device.
Well done,
@zzyxy!!
That RecoverExtendedSeeds is pure poetry.
That RecoverExtendedSeeds is pure poetry.
Credit goes to gpt-5.5. I'm just a messenger. :-)
On a side note, I've been amused and amazed at how much AI was able to do when I gave it access to ghidra, general description of how host and firmware interact with each other, and then told it to "go figure out how it verifies the checksum".
We live in interesting times.
My one had 0x00...
To wrap things up with
@_Wim_ 5442B's EEPROM:
- the device has a 8kB EEPROM.
- in this device, checksum doesn't use the LFSR14 method. It's pure sum of
unsigned bytes.
- the stored checksum is at offset [EEPROM_size - 258] and it's the unsigned sum of all the bytes up to that offset. In his case, current checksum = 0x800.
OTOH, my old 3205 uses the already mentioned LFSR14 method with signed bytes sum.
My one had 0x00...
To wrap things up with @_Wim_ 5442B's EEPROM:
- the device has a 8kB EEPROM.
- in this device, checksum doesn't use the LFSR14 method. It's pure sum of unsigned bytes.
- the stored checksum is at offset [EEPROM_size - 258] and it's the unsigned sum of all the bytes up to that offset. In his case, current checksum = 0x800.
OTOH, my old 3205 uses the already mentioned LFSR14 method with signed bytes sum.
I guess I was lucky then with my basic approach of +1 and -1. Did not expect Pico would have implemented so many different ways...
I had a brand spanking new 2204a delivered from element14 / Farnell today, not sure of the build date, but it's a 2205a now 🥰
i Could not get the python script to run in CMD . my cmd keeps flashing and cutting out after a hour or soo trying to fix this i got fedup and just generated a GUI which seems to work well . just place in same directory with eeprom scrypt .
i was able to get my 2204A upgraded to 2205A
