Electronics > Repair

HP 34401a DMM with leaking segments

<< < (40/45) > >>

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: ---
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;
  }
}


--- End code ---




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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod