External Display for Agilent 34401A (or any DMM with RS232 Output Stream)

[timb]

Good work dude! You were persistent and it payed off!

I might end up doing this instead of using an old 386 lunchbox with an ISA GPIB card, MS-DOS and Quick Basic.

[Harvs]

I thought this was a really good idea, so I've started playing around with it to.

I've just made up an adapter for my DMM using an RN42 module and MAX232.  I had them laying around already on boards so it was a no brainer.

So I've started writing an app.  Already I can see how useful this is going to be, however, I recon the 10.1" tablet I've got is too big for the bench.  So I think I'll get a 7 or 8" tablet and a swivel mount system that I can screw into the shelf so it doesn't take up bench space.

Anyway, hopefully we can collaborate in some way to make this work well.

If someone wants to send me some example serial captures from a 34401A (or any other meter for that matter.) I'll try to add support as I'm writing the app, then it'll be put up on google play for free.

[timb]

I've been looking around at different combinations of displays the last few days: TFT, eInk, OLED, Memory LCD and VFD. The idea was to make a "universal lab tablet" with onboard wireless, then I'd have little pods that could have a variety of interfaces (RS-232, GPIB) or even direct measurement modules (V/I/R, Oscilloscope, etc.)!

I've got the parts coming to do a GPIB interface (75160+75161) plus some sample displays (2.7" eInk, 2.7" Sharp Memory LCD, 128x64 VFD and some 1.5" color OLEDs) for the tablet portion. However, you just gave me a brilliant idea. I think I'll pick up a cheap 7" Android Tablet and start by just focusing the wireless pods. I can get super cheap (<$5) TTL serial to Bluetooth modules, so I'd put one of those in each pod and have it just connect to the tablet.

Are you interested in adding support to your app for them?

[Harvs]

Are you interested in adding support to your app for them?

Yeah of course.  Adding support for another device that streams is only going to be a couple of lines of code to deal with the packet format, or any bazar ascii chars the manufacturer decided to throw at it (and how you interrogate the device to get what function it's on, and range).  However if a device doesn't "stream" its readings, and needs to be polled, then that's a bit more work.

Bluetooth is easy and cheap.  It also has the advantage that you only need the two devices to work easily.  It's also been surprisingly robust on my bench.  However, TCP/IP via WiFi is also an option that could be used, and it looks like you can get modules off ebay for around $15ea that have RS232 output.  From the viewpoint of the Android device, it's very similar to work with.  Just a slightly different setup, i.e. look for an IP address instead of a pair device.

Most of the work from the app perspective is in getting the charts to display how you would naturally expect them to with all input conditions.  This actually isn't trivial, and requires a lot of manual code intervention to get it all to look right.  So yeah, adding more devices and/or features it the relatively easy part.  At first I'll be looking at everything the 34461A can do as a starting point for features.

[timb]

Okay, cool. Yeah, streaming wouldn't be a problem. Another option for WiFi is the CC3000 modules from TI (which cost $20 in one off quantities). They basically let you add WiFi to simple micros over SPI. The advantage is the SimpleLink Configuration software that runs on iOS/Android/PC and Mac, which makes getting the device on the network super trivial.

Anyway, I'll be starting with Bluetooth since that's super easy to implement. A feature I did want to have would be the ability to upload an "Instrument Configuration File" to the pod, which would (in the case of GPIB) contain information on the command sets the device(s) support or (in the case of RS232) the protocol of the device. This way the pod could send data back to your app in a device agnostic manner. (I.e., the microcontroller inside my pods will translate between a standard data format and whatever the instrument uses.) Perhaps use something like SCPI for the output format.

A nice advantage to having the pods be able to directly control the devices is you could use them as standalone data loggers as well.

[Harvs]

Nothing sounds hard, I'll keep coding and see where we end up.  I do quite like the pod idea, but don't get too worried about it having to be in a device agnostic manner.  I'm just coding in a drop down box to select the type of device you're connecting to, so any translation etc can be hidden behind that.

BTW the problem with not having streaming data, is how the tablet will know when a new reading is complete.  This is a common problem with SCPI instruments I've coded with.  On most, there's nothing you can even poll to check if a new reading is available, all you can do is get what is currently displayed on the screen which you have no way of telling whether it's a new reading with the same value or not.

[Galaxyrise]

BTW the problem with not having streaming data, is how the tablet will know when a new reading is complete.  This is a common problem with SCPI instruments I've coded with.  On most, there's nothing you can even poll to check if a new reading is available, all you can do is get what is currently displayed on the screen which you have no way of telling whether it's a new reading with the same value or not.

The two meters I'm familiar with are the Keithley 2000 and the hp 34401a.  Both have a way to "fetch me the next number" and a "measure into a buffer which I can dump (and then clear) at my leisure".

Funny how things converge; I was going to work on a little tool drive my K2K's scanner card and generate a csv or something, but the dern thing refuses to use the rs232 port (SCPI only, it says.) 

The idea of pulling that data to a tablet over bluetooth is very appealing indeed.  However, I'm worried that the bluetooth signal will get picked up in the measurements.  I've noticed that using my cell phone nearby will add noticeable noise.  I take it you don't see that with your bluetooth link?  I wonder why not.

[Harvs]

BTW the problem with not having streaming data, is how the tablet will know when a new reading is complete.  This is a common problem with SCPI instruments I've coded with.  On most, there's nothing you can even poll to check if a new reading is available, all you can do is get what is currently displayed on the screen which you have no way of telling whether it's a new reading with the same value or not.

The two meters I'm familiar with are the Keithley 2000 and the hp 34401a.  Both have a way to "fetch me the next number" and a "measure into a buffer which I can dump (and then clear) at my leisure".

Yeah I've only got Rigol gear and the Escort meter.  I understand that it's totally dependant on how the manufacturer has implemented SCPI, and hence it will require a bit more work to support each instrument if it requires specific register writes and reads.

Funny how things converge; I was going to work on a little tool drive my K2K's scanner card and generate a csv or something, but the dern thing refuses to use the rs232 port (SCPI only, it says.) 

The idea of pulling that data to a tablet over bluetooth is very appealing indeed.  However, I'm worried that the bluetooth signal will get picked up in the measurements.  I've noticed that using my cell phone nearby will add noticeable noise.  I take it you don't see that with your bluetooth link?  I wonder why not.

I haven't found any issues with radiated emissions, I believe bluetooth has a lot lower peak power than a typical mobile phone, also my meter is only 5.5 digit (looking for a 6.5 digit now).  However I have added bluetooth to embedded circuits before and found the noise it puts on the power rails to be horrendous (obviously this will be module dependant.)  So now I'm always sure to put the BT module on it's own separate regulator if I intend on using the uC's internal ADC.

As far as the bench meter goes, the BT module is at the back of the instrument, outside of the metal enclosure and away from anything it could couple into.  So no, I've seen no ill effects.

[quantumvolt]

...

BTW the problem with not having streaming data, is how the tablet will know when a new reading is complete.  This is a common problem with SCPI instruments I've coded with.  On most, there's nothing you can even poll to check if a new reading is available, all you can do is get what is currently displayed on the screen which you have no way of telling whether it's a new reading with the same value or not.

The 34401A has trig and measurement complete on separate plugs.

Nice to see that quite a few people works on this now. I am slow, but am working on it. May be I'll have BT next Christmas 

The other day I used serial data from the 34401A (current) and SPI-to-serial data from the LTC2400 24 bit ADC (voltage) in order to measure some precision resistors. As I needed to divide measurement pairs I read both datasets to an Arduino for math before sending all three datasets to the PC via USB and into a Processing sketch presenting V,I and R (one screen - from 2 instruments).

Point is - with a large tablet screen and a uC in between the instruments and the bluetooth transmitter you can send many datasets that goes into a summary screen or several small windows/GUIs on the tablet.

[bingo600]

@Harvs

Nics app 
This is taking an interesting turn 

I'd prob. also worry a bit about BT in the Lab , but only because i know GSM to disturb volt refs. quite a bit.

But i do have a feeling that GSM is quite gigh wattage , where BT and the WiFi coverage i have in there isn't.
So i guess the BT isn't a problem for normal lab usage.

Another way to make a cheap/easy "bus" would/could be RS-485 or I2C , and then convert that to RS232 just before hitting the tablet.

/Bingo

[PioB]

Hi all,

thank you very much for your code. I just got it working on an Arduino Mega with the Adafruit graphics libraries and an SSD1306 display.

Code: [Select]

#include <SPI.h>
#include <Wire.h>
#include <Adafruit_GFX.h>
#include <Adafruit_SSD1306.h>

#define OLED_MOSI   9
#define OLED_CLK   10
#define OLED_DC    11
#define OLED_CS    12
#define OLED_RESET 13
Adafruit_SSD1306 display(OLED_MOSI, OLED_CLK, OLED_DC, OLED_RESET, OLED_CS);

String inData;
int trigpin = 7;  // your choice, connect to DSR, serial pin 6


void setup()
{
  pinMode(trigpin, OUTPUT);
  Serial.begin(9600); // Serial hardware to PC
  Serial1.begin(9600);  // Serial1 on Arduino Mega2560 port to DMM
  display.begin(SSD1306_SWITCHCAPVCC);
  display.display();
  delay(2000);
  display.clearDisplay();
  display.setTextColor(WHITE);
  display.setTextSize(1);
  // Trigger
  digitalWrite(trigpin, HIGH);
  inData = ""; // Clear read buffer

}

void loop()
{
  digitalWrite(trigpin, LOW); //
  delay(10); // adjust
  digitalWrite(trigpin, HIGH);

  delay(1000);  // or whatever

  while (Serial1.available() > 0)
  {
    char received = Serial1.read();
    inData += received;
    // Process message when new line character is recieved
    if (received == '\n')
    {
      Serial.print("Arduino Received: ");
      Serial.println(inData);
      inData = inData.substring(0, inData.length() - 7); // cut exponent for test, see DMM manual for string format
      display.clearDisplay();
      display.setCursor(25, 29);
      display.print(inData);
      display.print(" V"); // a string - not a number - unparsed for exponent
      display.display();
      inData = "";
    }
  }
}

For future reference, here is how to put the 34401A into the "talk only" mode, took me a while: http://www.keysight.com/main/editorial.jspx?ckey=1000001249:epsg:faq&id=1000001249:epsg:faq&nid=-11143.0.00&lc=eng&cc=CO

[lukaq]

small, but looks good

[cellularmitosis]

ARISE FROM THE DEAD, YE THREAD!

I took a swing at this project this weekend, and spent a lot of time getting the values formatted the way I prefer.

I used a DB9 RS232-to-TTL adapter from eBay, and soldered a 10k pull-up from VCC to DSR (DB9 pin 6) to convince the 34401A to talk.

Also, the 34401A has been configured for "talk only" mode, so it just automatically spits everything out via the serial port; the Arduino doesn't have to transmit anything to the 34401A.

Details: https://gist.github.com/cellularmitosis/1582236f226e9d98075a0c971eb4168c

[cellularmitosis]

Update:

I forked the Arduino SoftwareSerial library to use two stop bits, as required by the 34401A.

Also, I tied pin 6 to 9v rather than 5v and that seems to have cleared up the occasional beep / error from the 34401A.

In my case, the adapter I was using was based off the MAX232, so I just found which capacitor had 9v on it and soldered the pin 6 pull up to that cap.

https://github.com/pepaslabs/SoftwareSerial2Stop