| Products > Test Equipment |
| Some old school instruments showing how it's done (HP 3325A and Fluke 8506a) |
| << < (33/91) > >> |
| garrettm:
Doh! I didn't notice that note on page 6 about 19200 baud operation. Even better than upgrading the crystal, it can already do it! I have firmware 6.07 that I can upload if you want to try flashing it. Maybe Fluke fixed the processing delay, whether artificial or accidental. |
| garrettm:
--- Quote from: SilverSolder on February 06, 2021, 05:16:34 pm ---Letting the meter do the averaging is probably the best - provided we can trust the numbers! --- End quote --- I would like to try emulating my DMM4050's trend plot, stats and histogram functions so I can compare the two for fun. Which necessitates getting as fast of readings from the DMM as possible. And I suppose I am curious if Fluke is full of crap with regards to how fast readings can be pulled off of these meters. After Joe's slow readback rate, I'm curious if it's an artificial cap or a firmware bug that’s holding back his meter. One of the main selling points of the 8505/6A's was its fast sampling and readback capabilities. Just compare specs with its rival the HP 3456A: 25 samples/s at 1PLC with AZ on and 48 samples/s with AZ off for 6.5 digits. Any faster than that and it loses resolution. The 8505/6A can do 5 times that while maintaining 6.5 digits! And being designed without an auto zero function, it is more stable than the HP 3456A under its best high speed sampling mode. |
| joeqsmith:
This meter has version 603 installed. Looks like its just a couple of 2764s. If you have the images already archived, yes please, upload them and we can at least get on the same firmware. If I change to use the internal asynchronous trigger, you can see the packet is now just five bytes rather than the six. There is no CR. Also notice that the meter sends the data slightly faster but again, no where near what I would expect. Maybe SilverSolder's meter has different firmware as well which may explain why their meter is faster. It's also VERY possible I am still not doing something properly which is throttling the system. |
| joeqsmith:
Looking at the sync signal, it shows up in the center of the serial packet. One per packet sent. I assume then this means the meter is not over sampling and is actually collecting the data this slow. I reset the meter and just looked at the sync, with no serial communications. Turning off the filter and setting the samples to 0, it's sampling at 21Hz. I'm thinking that I'm really missing something basic as there's nothing that should be throttling it. At least it doesn't seem at all related to the communications with the PC. |
| SilverSolder:
--- Quote from: joeqsmith on February 06, 2021, 09:41:08 pm ---This meter has version 603 installed. Looks like its just a couple of 2764s. If you have the images already archived, yes please, upload them and we can at least get on the same firmware. If I change to use the internal asynchronous trigger, you can see the packet is now just five bytes rather than the six. There is no CR. Also notice that the meter sends the data slightly faster but again, no where near what I would expect. Maybe SilverSolder's meter has different firmware as well which may explain why their meter is faster. It's also VERY possible I am still not doing something properly which is throttling the system. --- End quote --- Snowstorm tomorrow, perfect time to get GPIB working! :D I may be misremembering the speed of the Fluke: it was quite a while ago, it may have been an old HP 59313 A/D converter that I got running that fast... Time to get some accurate numbers. I will check what firmware revisions I have as well, it would be cool if we could upgrade all of them to the latest version! (Assuming the hardware is compatible throughout...) |
| Navigation |
| Message Index |
| Next page |
| Previous page |