Just wondering about a few use cases on the RBT2004?
(Modification: After I wrote this I discovered the RTM documentation for "R&S RTM-K1" and R&S - K15. I read another sheet that implying that the functionally of these options are the same for the RTB, Is that the case? If so my question is answered:) )
USE Case 1 - Long term serial decoding
With the memory upgrade of the RTB2004. If I set the scope to 10Ks per record, the manual says I can have 13107 records.
If I am; a) using a serial trigger (Say a given address, or some pattern) and b) assume I can fit a query response in one record based upon an assumption of approx. 2000 digital bits per record, yielding about 200 bytes of data.
1) Are the above assumptions reasonable?
2) Is each record stored uniquely (tagged), in 10Ks chunks? Is the serial decode information retained, or is it recalculated each time.
3) Assuming this is acting like segmented memory. How much time can elapse between triggered events? Basically, I want to know how long can I wait for bad stuff to happen? I my case, want to set up and then wander over to the remote sensors etc and, stuff them in crushed dry ice, wiggle wiggle (reference for our aussie friend) them like crazy and generally try to simulate nasty conditions that would cause the noise and communication failures. It sounds as if with 13k records I could go a very long elapsed time (well beyond my expectation, but there again ... expect the unexpected)
I answered this by reading https://cdn.rohde-schwarz.com/pws/dl_downloads/dl_common_library/dl_brochures_and_datasheets/pdf_1/RTB-K15_RTM-K15_Fast_ac_en_3607-1220-92_v0200.pdf
4) In the manual I see no mention of tabular representation of the decode. Is that available?
5) I assumed from my reading that I can save the 160 Ms history to a file for storage. If so could tests like the one above be saved for future analysis? I am particularly concerned about how decodes are replicated.
Use case 2 The function generator bit pattern capability.
Can the scope be setup and as a Master in an SPI Master/Slave configuration to generate queries?
If so what are the limitations?
I will continue to read through the remote control commands some more but I have a sense that the art of the possible might be very significant here.
Thanks in advance
PS Wife and daughter think I am absolutely crazy reading oscilloscope manuals...
My wife and daughter have looked at me the same way, especially when they open the garage and it is filled with oscilloscope boxes and my daughter can't get her bike out.
With respect to your questions that are still open on Use Case 1:
Q. Are the above assumptions reasonable?
A. Yes.
Q. Is each record stored uniquely (tagged), in 10Ks chunks? Is the serial decode information retained, or is it recalculated each time.
A. Yes, each segment has a time stamp. I'm not sure on how the serial decode information is done - I can tell you if it isn't stored it is basically done in real-time. As I "play" through the segments the decode instantly updates. If you need more insights, let me know and I'll talk with the factory.
Q. In the manual I see no mention of tabular representation of the decode. Is that available?
A. Yes. Please note though that it is just for the segment decoded (or the data captured if not in segmented mode). It doesn't bring all the data from every segment in to a single table.
Q. I assumed from my reading that I can save the 160 Ms history to a file for storage. If so could tests like the one above be saved for future analysis? I am particularly concerned about how decodes are replicated.
A. Yes, it is a very large file. But it is just the data - the decode itself isn't saved off. You can save off the decode separately, but it will only be for the segment displayed (if you don't use segmented you can save off the decode for the entire acq memory that you have in one capture which could decode lots of packets but may not work for you if you have huge amounts of idol time in between).
For use case 2, I haven't spent much time yet with the AWG, so I'll have to get back to you on it.
-Rich