HP 34401a DMM with leaking segments

[qu1ck]

I’m glad you got it working. I will publish the fix on github shortly, including the "no bootloader needed" firmware and better instructions.

To answer some of your questions:

Annunciator line with 4 digits is hexadecimal representation of 2 bytes where each bit corresponds to one of the glyphs on the display. For example 4th bit is for "Man" and 1st bit is for "*". So you see it changing between 0008 and 0009 meaning that "Man" is lit and "*" is flashing.
More is explained here https://github.com/openscopeproject/HP34401a-OLED-FW/blob/master/protocol.md

Continuity/diode mode spitting data out so fast that it crashes the firmware: as wictor guessed it's because of serial printing interfering with spi decoding. When serial buffers fill up because data is coming too fast the main firmware loop is blocked. You see the led on the bluepill flash for the same reason: this means main loop can not catch up to incoming data. This doesn't happen on release firmware so this is not an issue. And you should never use the meter while it's connected to your pc since your frontend will not be floating potential anymore.

[coromonadalix]

Yeah  i was lucky, nothing bad happened, i made sur not to connect the probes on anything,  even my cheap saleae logic analyser clone "cypress fx2"  was loading the data lines if the board was not suplied at the same time the 34401a dmm was powered on 

Time to reorder another oled ?? i hope this time i get it  loll         if you have your old board with the mask pcb problem to scrape,    i would take it


You wrote to me   your oled display project would be compatible with the old and newests front panels, right ?

thks @Quick1  for your project and help

[qu1ck]

New binaries are up on github
https://github.com/openscopeproject/HP34401a-OLED-FW/releases

I will update howto.md soon.

coromonadalix yeah I still have some boards left from first batch, I'll send you one.

New firmware is compatible with both old and new meters, correct.

[hakko]

Thanks @qu1ck for the job in protocol decoding... I also was able to do a dirty display for my meter  (new panel version) using my implementation.  I was tired of stm32 so i used a psoc 4 board that i have around. I used 2 spi ports as slave to get the data from the meter and a 16x2 crap lcd 

[qu1ck]

Yeah, that doesn't look half bad. You will have a hard time with annunciators though

[coromonadalix]

better than nothing eh  loll       hush hush  go find an oled display  loll

For the unused second line  he could write the function directly : cont, diode  in place of the icons ?

[hakko]

This setup was just to test the meter main board functions before full restore since i don't have gpib cable. It pass on self tests and on real test it's also fine

[bitseeker]

Nice test. If the display controller supports custom characters, that could make for some nice annunciators (if it was for longer-term use).

[6151kokodef]

I just bought one from eBay with serial number 3146A57XXX and it has the unobtainium NEC driver chip. It has dots after the characters. I replaced the VFD with one from ebay (Samsung SSVD branded) and it was like new - so glad it's not the chip.

It's an absolute pain to desolder the VFD with a solder sucker, so I put in turned pin sockets to make future troubleshooting and replacement easier.

[HighVoltage]

I just bought one from eBay with serial number 3146A57XXX and it has the unobtainium NEC driver chip. It has dots after the characters. I replaced the VFD with one from ebay (Samsung SSVD branded) and it was like new - so glad it's not the chip.

It's an absolute pain to desolder the VFD with a solder sucker, so I put in turned pin sockets to make future troubleshooting and replacement easier.

You also got lucky that the ebay VFD is working correctly. Not all of them do that.
Congratulations on a successful repair.

[floobydust]

I have one 34401a, new VFD fixed the polka dots problem - only for a while, when the DMM is hot they faintly appear. It is intermittent now.
The dots are a combination problem of aged VFD having low transconductance,  needing high drive voltage for blanking, as well as the NEC VFD driver PMOS aging getting old and lazy.

[dreamcat4]

got here the same problem, dots between the characters. and am going to leave it like this for the time being while considering options. you see maybe the oled would be lasting for a longer time than a new vfd, given the way the driver is already leaking and degraded as explained above here ^^. if it really cannot be replaced?

just am still a bit unsure. for example wanted to know if by installing the oled it might affects negatively the precision of measurements. but maybe there was already some testing with that in mind? and can see existing results for that? look up somewhere?

 

[floobydust]

The polka dot problem is caused mainly by both- an aging NEC MCU and VFD.
If you replace or rejuvenate the VFD display, it can work for a while longer. But I have one 34401a that polka dots sometimes show up as it runs warmed up.
So I started working on a replacement front panel board, to keep the stock VFD and just use a VFD driver+MCU compatible with the old main board firmware.

I forgot Qu1ck's schematic but plenty of power available from the unused filament winding on the tranny. Adding noise or load to +/-17.4V rails would affect the analog sections of the multimeter, I would not run the OLED power from that.

[dreamcat4]

thanks for these insights. so then i shall see what comes of this...

BTW checking the schematic on github here....

https://raw.githubusercontent.com/openscopeproject/HP34401a-OLED-HW/master/schematic.png

it seems qu1ck gets the power in from a +12v J5 marked there as DISPLAYPWR ?

not sure where that is supposed to hook up to. but yes that was my main concern with the oled mod.

in the meantime will also be patiently waiting to see if you can eventually replace the vfd driver in yours flooby. not in any particular hurry

[floobydust]

3.12" OLED need 12-15VDC at 25-50mA typ, depending on how much is lit up. About 2/3W.
If this is generated by an on-board boost-converter, it will draw a lot from a 3.3V rail, up to 250mA.
So how this is powered is important not to pollute or overload the 34401a power supply.

[qu1ck]

@dreamcat4

for example wanted to know if by installing the oled it might affects negatively the precision of measurements. but maybe there was already some testing with that in mind?

I don't have any precision standards to verify this, my 34401a is literally the most precise thing on my bench. But I did measure a AD587 based reference before and after the mod and the difference was well within temp drift of the source. Take that for what it's worth.

it seems qu1ck gets the power in from a +12v J5 marked there as DISPLAYPWR ?

not sure where that is supposed to hook up to. but yes that was my main concern with the oled mod.

On the display that I used there is a boost converter to 12v. I provisioned DISPLAYPWR hookup to use it as power source there and desolder/cut off the onboard converter on the display. I ended up not doing that because I couldn't measure any noise coupling into meters power lines. But the option is there.

@floobydust

3.12" OLED need 12-15VDC at 25-50mA typ, depending on how much is lit up. About 2/3W.
If this is generated by an on-board boost-converter, it will draw a lot from a 3.3V rail, up to 250mA.

Correct, 250mA is a very high figure though. In this application the display is only showing some text and small icons, at most 10-20% is lit up. My measurements showed <100mA load on the 3v3 line. That's including the stm32 microcontroller.

[dreamcat4]

those details are a great help and i appreciate the reply qu1ck. it would seem i am in a pretty similar situation over here. as it happens got some voltage refs from digikey recently. a few different ones but nothing ultra precision. and also a variety of common jellybean regulators. after watching dave's recent video on this topic, i stocked up

your solution looks pretty reasonable so please let me say thank you for your hard work there

[floobydust]

I took the 250mA value from example Blue 3.2" 256x64 OLED datasheet it's 3.3V boosted to 12V and 100% lit for 250mA. You can't pull that much off the +17.4V rail so I wasn't' clear where power is coming from, on the in-guard side.

[RikV]

Thanks for this great job! This will certainly be useful one day when I find a 34401A for a reasonable price....

[cellularmitosis]

Yes it can do via rs232 with the 31 address. It sends out strings (scientific floating point, like "+9.99995790E+00") with results.
For example you may read the rs232 strings with an external MCU and display them on any display you wish then..

Like this    https://www.eevblog.com/forum/testgear/external-display-for-agilent-34401a-(or-any-dmm-with-rs232-output-stream)/msg4344103/#msg4344103

[iMo]

I've been still thinking how to switch off the filament (my display is always off, but the filament is always on), I will do it with a simple switch placed somewhere on the rear, perhaps..

Btw. - this is what I did in past to deload my PC and save energy - there is the rear db9 serial connector, it has got 2 "free" pins (see the service manual).

I've been using one of the free pin as a 5V source (off the 5V outguard regulator placed nearby, via a 4R7 and 100nF to gnd) for the powering the external mcu.

The second free pin has been used as the output of the internal LM35 temperature sensor (powered off the 5V outguard vreg).

The meter's rs232 to cmos 3V3 level is simply done via a transistor (the bluepill reads the incoming data only).

As I wrote in past here there is the BT HC-05 sending data (115k2) off the bluepill to any external device (a cheapo smartphone with serial terminal in my case) logging the data coming off the bluepill (and I make 2x 16bit temperature measurements,  temperature/gain compensation, averaging/smoothing of any kind, stddev, all in float64, incl. time/date capture from DS3231 in that bluepill, sending all the results upon each new sample as a .csv record).
Thus the total power consumption with long measurements is minimal (except the filament)

[mmx01]

Hi,

Maybe this is a bit necro-posting but I am trying to adapt this solution to another instrument and another MCU. I am working on a damaged E3632a which appears to share a lot of HW/design with 34401a, it did not survive shipping and complete front panel is in pieces. VFD did not survive and other parts suffered as well... so trying to see what I could save and cannot verify what is really operational control wise. There is some life but faar from ideal.

Changes for me are using ESP32 instead of STM32 and after adapting the platform, I get a lot of errors with decoding. ESP32 runs at 240Mhz/40Mhz crystal so speed should not be an issue. Using external interrupt to capture following 8 bits per original routine. For now I don't output to LCD/Oled and modified the SW (interrupt routine) to ESP32. I read all bytes to a char buffer dumping them to serial only once every 500 EOF messages.

So there shouldn't be loop/delay issues while collecting 500 samples since I am not triggering serial output more than once every 500 messages. Also I set baud to 1Mbit on both ESP32 and the terminal.

Code: [Select]


void IRAM_ATTR sckInterrupt() {
  // mid byte power on detection
  now_us = micros();
  if (byte_len != 0 && (now_us > (last_us + 1500))) { //MAX_SCK_DELAY
    byte_len = 0;
  }
  last_us = now_us;
  output_acc = (output_acc << 1) + ((GPIO.in >> 23) & 1);
  input_acc = (input_acc << 1) + ((GPIO.in >> 18) & 1);
 
  byte_len++;
  if (byte_len == 8) {
    if (byte_ready) {
      byte_not_read = true;
    }
    input_byte = input_acc;
    output_byte = output_acc;
    byte_len = 0;
    byte_ready = true;
  }
}

void startSniffing() {
  attachInterrupt(digitalPinToInterrupt(19), &sckInterrupt, RISING);
}

inline void endFrame() {
  buf_len = 0;
  frame_state = UNKNOWN;
  mi++;
  if(mi == 500) {
    for(int z=0; z<mi; z++) {
      for(int x=0; x<15; x++)
       Serial.print(mb[z][x], HEX);
      Serial.println(".");
    }
  mi = 0;
  }
}





By default it says "   OUTPUT OFF   " for a message type decode but we can clearly see bits missing/errors in some of the messages. I am a bit lost as to why would this be other than perhaps HW fault.

14:56:20.802 -> 204F5554505554204F464620000.
14:56:20.802 -> 204F5554505554204F464620000.
14:56:20.802 -> 204F5554505554204F464620000.
14:56:20.802 -> 204F5554505554204F464620000.
14:56:20.852 -> 204F5554505554204F464620000.
14:56:20.852 -> 204F5554505554204F464620000.
14:56:20.852 -> 204F5554505554204F464620000.
14:56:20.852 -> 204F5554505554204F464620000.
14:56:20.852 -> 204F555450555C204F464620000.
14:56:20.852 -> 204F5554505554204F464620000.
14:56:20.852 -> 204F5554505554204F464620000.
14:56:20.852 -> 204F5554505554204F464620000.
14:56:20.852 -> 204F5554505554204F464620000.
14:56:20.852 -> 204F5554505554204F464620000.
14:56:20.852 -> 204F5554505554204F464620000.
14:56:20.852 -> 204F5554505554204F464620000.
14:56:20.852 -> 204F5554505554204F464620000.
14:56:20.852 -> 04F5554505554204F464620000.
14:56:20.852 -> 204F7554505554204F464620000.
14:56:20.852 -> 204F5554505554204F464620000.
14:56:20.852 -> 204F5554505554204F464620000.
14:56:20.852 -> 204F5554505574204F464620000.
14:56:20.852 -> 204F555450555404F464620000.
14:56:20.852 -> 204F5554505550204F464620000.
14:56:20.852 -> 204F555C505554204F464620000.
14:56:20.852 -> 204F5554501554204F464620000.
14:56:20.852 -> 204F5554505554204F464620000.

[qu1ck]

Judging by the fact that you have half of a hex digit missing in the output in some cases the fault is much more likely in your uart and not decoding. Try lower baud rate or different uart chip.

[mmx01]

I thought about this as well but UART is already another attempt due similar issues I have faced with i2c connected oled. Similar defects are happening also via i2c with UART completly removed from the loop. You use parallel interface and I thought initially it may be due i2c being slower and standard SSD1306 libraries requiring display.display() to push the entire buffer out, taking extra cycles with capture/decoding still running (explaining missing bits/sometimes bytes) but the same happens via serial.

Now I started thinking about reducing number of variables and getting STM32 dev board instead of ESP32 (although I did not immediately see why it wouldn't work). Tested it also with 10k resistors on the SCK/MISO/MOSI lines but ESP32 is 5V tolerant and same defects appeared with or without the resistors towards the FP (exluding issue of overdriving pins).

[qu1ck]

> Similar defects are happening also via i2c with UART completly removed from the loop

Similar is not the same. When you print a hex digit to uart and only see one char instead of 2 that means your uart is borked, no other explanations.
Missing bits can be explained by timing or by slow IO (io clock is not the same as core clock) or by ringing (check connections).

If you have timing issues you can check 2 things
1. Every byte is read as soon as it comes in, my code has a check provisioned for it. On the original board it lights up an error led if SPI bits are coming in faster than the board can process them.
2. Every frame is processed before next frame comes in. Time between frames is a lot bigger than between bits so you can accurately measure it in code itself and check if your display output routines are fast enough.