A few graphics issues have made it into this release as well, as the attached screenshot shows.
Square-wave on channel 1.
Measurement added (peak-peak).
Zoom enabled (exact settings are visible in the screenshot).
Hit the Run/Stop button (history navigation appeared).
Added second measurement (rise -time).
Scrambled overplayed graphics appeared.
BR,
Michael
Thanks Michael for the very detailed instructions on how to replicate this. I'll submit it to our bug fix queue.
-Rich
Hi!
My first post here but I hope that its useful for those who have bought their RTB's without
the PK1 option bundle and are a bit irritated because of the current offer from R&S to get
a 50% discount for the PK1 when buying it together with a new scope.
The offer is also on Farnell but it seems that the system has discounted the PK1 to 50%
of its original cost but does not require to add a scope to the basket. So get your option
bundles while they last or while Farnell notices this bug and fixes it
I got mine already.
With best wishes,
Marek
Hi!
My first post here but I hope that its useful for those who have bought their RTB's without
the PK1 option bundle and are a bit irritated because of the current offer from R&S to get
a 50% discount for the PK1 when buying it together with a new scope.
The offer is also on Farnell but it seems that the system has discounted the PK1 to 50%
of its original cost but does not require to add a scope to the basket. So get your option
bundles while they last or while Farnell notices this bug and fixes it I got mine already.
With best wishes,
Marek
Also, in UK at least, remember you can get 4% cashback on Farnell orders via Quidco
.....................
With respect to your question on the duplex buses, I have a guess, but I'll also confirm with our R&D team. I believe it is due to our hardware implementation of bus decoding in a FPGA. We tried to simplify the setting up of a duplex bus (which I believe we did), but we weren't able to completely reconfigure the FPGA to handle a duplex bus on a single decode at this time. Having said that, we know that several people would like the ability to decode a full duplex bus and another bus simultaneously and we'll continue to keep that on the potential enhancement list for future updates.
-Rich
I found that very disappointing too.
It's a true deal breaker and something that I don't expect in this price range.
Regards,
0xfede
.....................
With respect to your question on the duplex buses, I have a guess, but I'll also confirm with our R&D team. I believe it is due to our hardware implementation of bus decoding in a FPGA. We tried to simplify the setting up of a duplex bus (which I believe we did), but we weren't able to completely reconfigure the FPGA to handle a duplex bus on a single decode at this time. Having said that, we know that several people would like the ability to decode a full duplex bus and another bus simultaneously and we'll continue to keep that on the potential enhancement list for future updates.
-Rich
I found that very disappointing too.
It's a true deal breaker and something that I don't expect in this price range.
Regards,
0xfede
Totally understand and hopefully it is something we can address in a future release. I've made sure your feedback (and others) is known.
-Rich
The Signal Path just posted:
Rohde & Schwarz RTB2004 10-Bit, 2.5GS/s Mixed-Signal Oscilloscope Review, Teardown & Experiments
^ I wonder what FW version? Hopefully Rich gets a chance to watch the complete video, Shahriar uncovered a couple more opportunities for improvement.
Excellent video as well.
It's not the latest firmware unfortunately. I must say I disagree with Shahriar about the detented knobs!
Video is good so far, but employment got in the way of watching the whole thing
It's not the latest firmware unfortunately. I must say I disagree with Shahriar about the detented knobs!
Video is good so far, but employment got in the way of watching the whole thing
I installed the latest firmware a week ago. Has there been an update since then?
I know the knobs is a matter of taste, I personally really like them.
I installed the latest firmware a week ago. Has there been an update since then?
I know the knobs is a matter of taste, I personally really like them.
A significant update, v2.0, was released on November 29th.
It's not the latest firmware unfortunately. I must say I disagree with Shahriar about the detented knobs!
Video is good so far, but employment got in the way of watching the whole thing
Yes, the now-working UART framing would have helped for his demo. Pretty sure I had Uart trigger working though surprised it didn't wirk fir him.
Also can't see how clicky fine knobs are better.
I installed the latest firmware a week ago. Has there been an update since then?
I know the knobs is a matter of taste, I personally really like them.
A significant update, v2.0, was released on November 29th.
That is unfortunate! I missed it by one day...
Great video, thanks for your work.
I checked and on V2.00 fw the UART pattern triggering is working.
A bug that I found is that if you try to modify the UART TX (secondary) treshold level it doesn't change. The only way to modify it is to continously push the 'Find Treshold' button until the value is the one you want.
Just for fun I'm attaching an FFT of 868MHZ FSK modulated signal (I've used an external 50ohm terminator).
Best,
0xfede
A few other comments having watched the video:
- The list of icons along the top left can be changed by tapping the cog icon in the top-middle of the screen
- Definitely aliases in "Sampled" acq mode. Could try using "Peak Detect" mode?
- As well as the bus table, FFT/Delayed modes with the split screen allow for relative size of each section to be changed
- Agree RE 50ohm inputs @ 300MHz - I end up using pass-through terminations quite a bit
- Screen protector works very well, but in my setup (which doesn't have lights that reflect on it) I prefer the screen without one.
- ARB gen using non-built-in waveforms has a rather low sampling rate, which unfortunately limits it a bit and leads to jitter of edges etc
Thanks for the video - nice to see one showing the scope actually in use!
Yes, excellent clear and professional review. I always learn things watching your videos. Thanks Shahriar.
I had a chance to play around with the latest firmware over the weekend and I am fairly impressed. Several GUI issues I had reported were not mentioned in the release notes, so I was quite relieved that they had been fixed as well.
One issue I had noticed (but never reported) before the firmware update has not been corrected though. Incorrect data is saved when downloading a .csv file of the acquisition memory of a trace that has not been allowed to complete. I noticed this when using the scope for some ad-hoc datalogging with the timebase set to 500s/div, but it can be recreated with any timebase slow enough that you can hit Run/Stop before the full trace data is collected.
The attached examples were taken with Single trigger mode and Acquisition Record Length of 20MSa. The first one (scrprint1/plot1) was allowed to complete and the downloaded data appears correct, while the second one (scrprint2/plot2) was stopped early with the Run/Stop button. The .csv files are downloaded through the network interface and the plots are generated with Octave+gnuplot, and I have manually examined the .csv file contents to verify that the plots are accurately representing the data in the files. I'd upload the .csv files as well but they are ~500MB
The data content of the early terminated traces can vary - I know at various times I've seen random data, discontinuous data like shown in the second example here, and even continuous data that appears to be from the correct waveform but with incorrect phase/timestamps. I'm sure it is related to the previous operations on the scope, but I haven't quite figured out a pattern to it yet.
It is also interesting that the pre-trigger data is never shown on the early-terminated trace. On the trace that is allowed to finish the pre-trigger data is not displayed until after the trace completes, so it seems possible that there is some sort of post-trace processing that is being missed that leads to the download being incorrect.
Thanks Hugoneus - Perfect timing as I've been considering this scope the last few weeks. Although my 17year old may 'borrow' it off me for his A-level project
The quality and depth of your reviews is first rate. Some of it goes over my head but, if it didn't, I wouldn't learn anything new.
Shahriar,
Thanks for the review of the scope, I always learn something. One point, if you tap the gear on the task bar you can change the apps displayed and replace the education app with one that suits you better.
Rob
The Signal Path just posted:
Rohde & Schwarz RTB2004 10-Bit, 2.5GS/s Mixed-Signal Oscilloscope Review, Teardown & Experiments
Thanks for reviewing ...
The problem with the UART might be that you have a continuos stream of UART data.
The trigger type you have choosen needs to have a break event before to detect a clean start of frame.
Great video, thanks for your work.
I checked and on V2.00 fw the UART pattern triggering is working.
A bug that I found is that if you try to modify the UART TX (secondary) treshold level it doesn't change. The only way to modify it is to continously push the 'Find Treshold' button until the value is the one you want.
Just for fun I'm attaching an FFT of 868MHZ FSK modulated signal (I've used an external 50ohm terminator).
Best,
0xfede
0xfede - thanks for the feedback on the UART threshold. The team was able to recreate this and has added it to the bug fix tracker. There is also a workaround in the meantime - you can change the threshold in the channel menu.
-Rich
I had a chance to play around with the latest firmware over the weekend and I am fairly impressed. Several GUI issues I had reported were not mentioned in the release notes, so I was quite relieved that they had been fixed as well.
One issue I had noticed (but never reported) before the firmware update has not been corrected though. Incorrect data is saved when downloading a .csv file of the acquisition memory of a trace that has not been allowed to complete. I noticed this when using the scope for some ad-hoc datalogging with the timebase set to 500s/div, but it can be recreated with any timebase slow enough that you can hit Run/Stop before the full trace data is collected.
The attached examples were taken with Single trigger mode and Acquisition Record Length of 20MSa. The first one (scrprint1/plot1) was allowed to complete and the downloaded data appears correct, while the second one (scrprint2/plot2) was stopped early with the Run/Stop button. The .csv files are downloaded through the network interface and the plots are generated with Octave+gnuplot, and I have manually examined the .csv file contents to verify that the plots are accurately representing the data in the files. I'd upload the .csv files as well but they are ~500MB
The data content of the early terminated traces can vary - I know at various times I've seen random data, discontinuous data like shown in the second example here, and even continuous data that appears to be from the correct waveform but with incorrect phase/timestamps. I'm sure it is related to the previous operations on the scope, but I haven't quite figured out a pattern to it yet.
It is also interesting that the pre-trigger data is never shown on the early-terminated trace. On the trace that is allowed to finish the pre-trigger data is not displayed until after the trace completes, so it seems possible that there is some sort of post-trace processing that is being missed that leads to the download being incorrect.
Hi Fgrir - thanks for the feedback and sorry for the trouble. The team was also able to recreate this and it will be fixed in the next update.
-Rich
Great video, thanks for your work.
I checked and on V2.00 fw the UART pattern triggering is working.
A bug that I found is that if you try to modify the UART TX (secondary) treshold level it doesn't change. The only way to modify it is to continously push the 'Find Treshold' button until the value is the one you want.
Just for fun I'm attaching an FFT of 868MHZ FSK modulated signal (I've used an external 50ohm terminator).
Best,
0xfede
0xfede - thanks for the feedback on the UART threshold. The team was able to recreate this and has added it to the bug fix tracker. There is also a workaround in the meantime - you can change the threshold in the channel menu.
-Rich
Here is one more funny UART "Feature"
I'm doing 921600 bit/s.
When I type it into the Bit Rate - User field - it is parsed first time as 919.12 kBit (how big are your kBits?) - but 2nd time entering the EXACT same number it is parsed as 930.07 kBit/s. 3rd time we are back at 919.12kBit/s - 4th time 930.06kBit/s - and so on...
Neither is related to 1000 OR 1024 dependent on how many bits you think is in a kilo of Bit's.
But I'm not very impressed by the serial decoding either. Please put some effort into that for next firmware version.
Great video, thanks for your work.
I checked and on V2.00 fw the UART pattern triggering is working.
A bug that I found is that if you try to modify the UART TX (secondary) treshold level it doesn't change. The only way to modify it is to continously push the 'Find Treshold' button until the value is the one you want.
Just for fun I'm attaching an FFT of 868MHZ FSK modulated signal (I've used an external 50ohm terminator).
Best,
0xfede
0xfede - thanks for the feedback on the UART threshold. The team was able to recreate this and has added it to the bug fix tracker. There is also a workaround in the meantime - you can change the threshold in the channel menu.
-Rich
Here is one more funny UART "Feature"
I'm doing 921600 bit/s.
When I type it into the Bit Rate - User field - it is parsed first time as 919.12 kBit (how big are your kBits?) - but 2nd time entering the EXACT same number it is parsed as 930.07 kBit/s. 3rd time we are back at 919.12kBit/s - 4th time 930.06kBit/s - and so on...
Neither is related to 1000 OR 1024 dependent on how many bits you think is in a kilo of Bit's.
But I'm not very impressed by the serial decoding either. Please put some effort into that for next firmware version.
Thanks kaz911 for the feedback. Can you elaborate on other areas you'd like to see improved on the serial decoding front?
-Rich
Thanks kaz911 for the feedback. Can you elaborate on other areas you'd like to see improved on the serial decoding front?
-Rich
I would like a persistent grab in Bus Table Option - so do not clear Bus Table display before next decoded data rolls in - or roll paper mode so data stays on screen on new lines.
I would also like "realtime"
decoding before end of scan but I think that might not be possible. Seems like decode happens at the each update interval only. So if you "slow roll" the decode does not happen until "cursor" reach end of screen. At which point a new packet normally starts shortly thereafter - clearing the Bus Table display .... But above mentioned option would help.
Like Mike I would like more than one symbol in a message - now I specify a longer hold-off "Idle Time" to get all the chars on one line in the Bus-Table. In that would be nice to have in the decode screen as well. So everything before the Idle-Time is not split into many hexagons but stays within 1 making it infinitely more readable
Next week I'll do some CAN debugging so lets see how that goes (NMEA 2000/DeviceNet cousin)