Thanks for posting the info, have you tried using a custom cab to dump the entire filesystem to a flash drive?
I agree this would be super-useful. It's something I have (and will continue to) pitch, but it's a tricky thing to do without giving away our secret sauce.
What would really steal sales from the DS1054Z in my opinion would be if Keysight decided to open up the API for writing third party decoder plugins. How easy or practical this would be given their software architecture, I have no idea.I agree this would be super-useful. It's something I have (and will continue to) pitch, but it's a tricky thing to do without giving away our secret sauce.
I agree the DSOX1000 has enough channels to capture the SPI Clock, MOSI, and MISO. However the FPGA that performs the decode within the scope has only one decoder path. A big benefit of using the FPGA to perform hardware-based decode is that it can decode in real time, capturing rare events as they happen. With this hardware limitation it means that the number of decoded buses cannot be easily expanded in the scope. The scope supports decode of only 1 bus at a time. MOSI and MISO would have to be treated as two separate buses.
My description was an over simplification. The oscilloscope can decode both directions of UART, both TX and RX, at the same time. With the UART protocol there are no other signal qualifiers so it requires fewer resources. Decode can be performed with only TX and RX signals. The minimum for SPI is the Clock and either MOSI or MISO, with CS being optional.
I hope you’ll consider the Keysight DSOX2004A 70MHz oscilloscope or DSOX2014A 100MHz oscilloscope. These 4-channel oscilloscopes have twice the FPGA resources so they can decode the full 4-wire SPI, both the MISO and MOSI, at the same time.
It's probably about total FPGA resorces, assuming it isn't loading a protocol-specific bitstream. If it was, then I wouldn't expect there to be a limitation unless it's extremely full. SPI has stuff like an edge counter, which may account for it using more resources than uart.
ISTR the1000 uses a smaller FPGA than the 3000, not sure about the 2000
There's also an FPGA.I wouldn't expect decode functionality to be nailed into an ASIC,except maybe display support.
They wouldn't want to exclude the possibilty of adding new decodes in future.
There's also an FPGA.I wouldn't expect decode functionality to be nailed into an ASIC,except maybe display support.
They wouldn't want to exclude the possibilty of adding new decodes in future.
It's built into the ASIC:
Thread being locked as this has become a slanging match between scope manufacturers!
EDUX front end mod to DSOX partial results.
<snip>
Second picture shows the hardware mod of the front end. The hardware mod is partial because I am waiting for the solder paste to arrive to be able to solder the WSON Package
With the actual hack/ mod knowledge, what can I expect from a Keysight Edux 1000X hacked/moded
How a 30 Mhz SPI signal with regular probes appear on the Edux screen
Here a reference for the same signal on Rigol 1054Z hacked with regular probes ( not spring ) based on ESP32 generating a counting SPI
With the actual hack/ mod knowledge, what can I expect from a Keysight Edux 1000X hacked/moded
How a 30 Mhz SPI signal with regular probes appear on the Edux screen
Here a reference for the same signal on Rigol 1054Z hacked with regular probes ( not spring ) based on ESP32 generating a counting SPI
Second picture shows the hardware mod of the front end. The hardware mod is partial because I am waiting for the solder paste to arrive to be able to solder the WSON Package
You don't need solder paste for that
Flux and tin the pads with a soldering iron (and optionally wick off the excess), do the same on the LMH6552, dab a bit more flux on the board, and hot-air it into place.
Second picture shows the hardware mod of the front end. The hardware mod is partial because I am waiting for the solder paste to arrive to be able to solder the WSON Package
You don't need solder paste for that
Flux and tin the pads with a soldering iron (and optionally wick off the excess), do the same on the LMH6552, dab a bit more flux on the board, and hot-air it into place.I tried with a flux pen (liquid that evaporates very quickly) and it didn't work well. I did not have a lot of time to do it, so I can repeat today. I ordered flux paste as I expect it to work better than the liquid flux pen for this type of application.
Thanks for the suggestion.
There's also an FPGA.I wouldn't expect decode functionality to be nailed into an ASIC,except maybe display support.
They wouldn't want to exclude the possibilty of adding new decodes in future.
It's built into the ASIC: