Products > Test Equipment
Some old school instruments showing how it's done (HP 3325A and Fluke 8506a)
<< < (32/91) > >>
garrettm:

--- Quote from: joeqsmith on February 06, 2021, 02:00:49 am ---The fastest I can pull down data is about 65ms a sample.  That's with S0 (4ms), filter off and internal triggering.  The software is just pulling out data when it's available and stitching it together.  Another process checks for a valid frame and pulls it out to be processed.   The serial port only supports up to 9600 BAUD.  They also have a minimum of 2 stop bits.  A message is 14 bytes (using ASCII), or 14.6ms to send.   I tried using asynch which brought it down to 54ms  but it seems like it's slower than it should be.    Maybe the binary format would improve it.   

What are you able to achieve when using GPIB?

--- End quote ---

I'm still in the process of getting my GPIB setup figured out, but I should have it up here soon. (It's much more complicated than serial!)

Looking at Tables 606-1 through 606-3. The Bit Serial Interface can be set to 1 stop bit (S3 on) and no parity (J3 removed).

Assuming the remaining jumpers and switches are set to

J1 installed
J2 removed
S1 off
S2 off
S4 off
S5 on
S5 on
S7 on

the serial bus would be configured for 9600bps RS232C with 1 start bit, 7 data bits, 0 parity and 1 stop bits, for a total of 9 bits (7N1) transmitted for each char.

This implies a maximum of 1067 chars per second over the bus. Each reading from the DMM is a string of length 13. Then we have the termination chars <CR> and <LF> tacked on for a total of 15 chars per reading. This implies a maximum of 71 6.5 digit readings per second.

Using command J to suppress the <LF> termination character allows for a maximum of 76 6.5 digit readings per second.

Since ASCII data over the serial bus is so slow, changing the DMM's sampling rate to S1 or S2, would allow you to perform some averaging at the DMM without lowering the reading rate at the PC. This would indirectly get you closer to the 250 samples/s reading rate, if cheating somewhat by "compressing" more samples in to each reading.

Assuming binary data and 8N1 frame length, then 960 bytes can be transmitted per second. Each reading of the DMM is then 6 bytes. Assuming terminating chars <CR><LF> are tacked on at the end of the payload, then a maximum of 120 readings per second are possible. (Or 137 if line feed is suppressed.)

Looking at the schematic for the Bit Serial Interface circuit, it seems like it would be pretty easy to modify. The serial port and level shifters could be replaced with a TTL level RS232 to USB or Ethernet board for ease of use. Though the bus would still be limited to 9600bps and no hardware flow control. It's possible that modifying the circuit around U3 could allow for higher baud rates. Though replacing U9 with an Arduino Micro would give hardware flow control and much faster communication over the virtual COM port. This would be even faster than the stock GPIB interface.
joeqsmith:
Looks like I had sorted out the stop bits before.   The previous data was taken with eight data bits and a one stop.  10-bits/byte.   9600bps/10 = 1.04ms/byte.  With 14 bytes I get 14.58 or the 14.6 I mentioned earlier.   It's not a bit or byte off here or there, its a long way off.   

I doubt I will invest anytime modifying the meter but I may try the binary format.     

**********
The manual mentions a high speed reading mode "!" but it's only supported with parallel and GPIB.   I tried it anyway with the serial interface and it doesn't appear to work.  No surprise.   

Binary does improve things a bit.   The meter sends out 6 rather than 14 bytes.   About an 8ms difference.  Looks like it takes about 32ms per reading vs 54ms using ASCII.   One thing I notice is if I use asynchronous trigger, the unit suppresses the carriage return.   So there would be some gains there if I were able to sort out a way to synchronize with the data.
The other thing I noticed is when I use binary, regardless of the trigger setting, the display is off.     
   
The schematic shows a AY-5-1012 UART but the BOM shows a 13.  Looking at the clock generator, it looks like little effort to run it at 19.2kbps.     
http://sintran.com/sintran/library/libother/extern/F4702.pdf
SilverSolder:

Letting the meter do the averaging is probably the best - provided we can trust the numbers!
garrettm:

--- Quote from: joeqsmith on February 06, 2021, 02:55:19 pm ---[...]
The manual mentions a high speed reading mode "!" but it's only supported with parallel and GPIB.   I tried it anyway with the serial interface and it doesn't appear to work.  No surprise.   

Binary does improve things a bit.   The meter sends out 6 rather than 14 bytes.   About an 8ms difference.  Looks like it takes about 32ms per reading vs 54ms using ASCII.   One thing I notice is if I use asynchronous trigger, the unit suppresses the carriage return.   So there would be some gains there if I were able to sort out a way to synchronize with the data.
The other thing I noticed is when I use binary, regardless of the trigger setting, the display is off.     
   
The schematic shows a AY-5-1012 UART but the BOM shows a 13.  Looking at the clock generator, it looks like little effort to run it at 19.2kbps.     
http://sintran.com/sintran/library/libother/extern/F4702.pdf

--- End quote ---

Would replacing the 2.4576MHz crystal with a 4.9152MHz part do it? Almost seems too easy... May need to check the level shifters to see if they can do 19.2k baud. Otherwise it seems like a low cost upgrade--literally less than a dollar.

I'm still confused why your meter reads so slowly. While the numbers I ran are upper bounds, since they don't take into account processing delays and the transit time for data to move from the PC to the DMM and back, they still should be within 20% of actual throughput.

Have you tried using command J to suppress the line feed termination? Using two termination characters is pretty wasteful.
joeqsmith:
I have been using the J command to get the 14 byte payload when using ASCII.   I have not tried to enable it after changing to binary format to see if it actually will still add it.       

Adding the jumper from data sheets I linked previously, oddly running at 19.2k I see no further gains.  It seems to be capped out around 30ms per transfer.    Again, 8N1 or 10bits per byte or 1.92kBps, with a payload of  6 bytes it should be in the 3ms range.     

Looking at the serial data, we can see the meter sends out a packet pretty much every 30ms.    Again, the PC is not sending any data to the meter.  I just have the meter send it as fast as it can.   

***
I wonder if they cap it in their firmware based on the interface.   They know the card only supports 9600, so they only service it at that expected rate.  Odd choice if that's the case.

 
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod