HP 34401a DMM with leaking segments

[mmx01]

I have wired red led with flag byte_not_read. With oled configured it does turn on from time to time but this is not aligning with oled defects.

With led off defects still appear. However without oled, red led does not come on.

Agreed serial issues appear independent from oled issues in a sense for oled there's more a bit flip issue than half byte lost with serial.

I put some time captures in SW, for message to message the period measured from first interrupt until EOF is avg. 116800us = 8.5Hz. Since I push the buffer out to display on EOF (all bytes in the buffer), I would expect it to be okay. i2c could handle up to 40fps, so there's room there. i2c is set to 400kHz.

https://youtu.be/vYpie1gxGXQ


For ringing mitigation I put short cables and series resistors but little to no change. Will try with STM32 tomorrow and if not getting anywhere will get a cheapo logic analyzer.

18:00:57.821 -> 204F5554505554204F 64620000.
18:00:57.821 -> 7474757972737674757476757500.116407.
18:00:57.821 -> 204F5554505554204F464620000.
18:00:57.821 -> 7574767579747574747474747600.116918.
18:00:57.821 -> 204F5554505554204F464620000.
18:00:57.821 -> 7474747574787576747675737700.116913.
18:00:57.821 -> 204F5554505554204F464620000.
18:00:57.821 -> 7677737673757574737676747700.116896.
18:00:57.821 -> 204F5554505554204F464620000.

[mmx01]

So with STM32F4 board everything works fine with the same i2c oled... no defects. Processing time for each byte has not changed between ESP32 and STM32 however, frame processing time is 26% faster with STM32.

Indeed ESP32 GPIOs are not running at 240MHz like the cores do, but still the APB bus runs on 80MHz. I had not expected issues with the ESP32 performance for this not very complex decoding task yet empirically it proves to be the case.

Now I can move on to mapping other codes for different display features.

15:57:13.908 -> 204F5554505554204F464620000.
15:57:13.908 -> 7474747475747474747574747400.86855.
15:57:13.908 -> 204F5554505554204F464620000.
15:57:13.908 -> 7474757474757575757474747400.86555.
15:57:13.908 -> 204F5554505554204F464620000.
15:57:13.908 -> 7474747475747474757574747400.85627.
15:57:13.908 -> 204F5554505554204F464620000.
15:57:13.908 -> 7574747475747474747474747400.85136.
15:57:13.908 -> 204F5554505554204F464620000.
15:57:13.908 -> 7475757474747475747474747500.86854.
15:57:13.908 -> 204F5554505554204F464620000.
15:57:13.908 -> 7574757474747475747475747400.86554.
15:57:13.908 -> 204F5554505554204F464620000.
15:57:13.908 -> 7574757574747474747475747400.86043.
15:57:13.908 -> 204F5554505554204F464620000.
15:57:13.908 -> 7574747474757574747475757400.86556.
15:57:13.908 -> 204F5554505554204F464620000.
15:57:13.908 -> 7574747474747474747574747500.86556.

[floobydust]

How are you doing the level-translation, do you have a schematic? Just to see if that is the problem.
I would also ensure the radio is turned off to prevent TX packets from making interference and power system spikes, in active mode it can spike to 250mA.
I have the rotary encoder bits reverse-engineered somewhere and will look for that when I get a chance.

[mmx01]

With ESP32? Level shifting is not needed, IO is 5V tolerant.

[floobydust]

With ESP32? Level shifting is not needed, IO is 5V tolerant.

No mention of 5V tolerance in Espressif datasheets "3.6V max" so I treat it as that. The hiccup looked periodic in the video, happens at a regular interval so something else must be at play.
Changing to the STM32, one way to solve it.

[mmx01]

You are right about the datasheet, for official use I would not push it. For hobby I did many times and "the internet" is full of statements it does. While it is not in the datasheet, it does support 5V when VCC is 3.3V.

As to how I would approach level shifting, resistor dividers may not be fast enough and when I play with FPGAs and 5V->1.8V (older 5VCMOS or TTL logic) I resort to gtl2000dgg. Quite fast for such projects at 33MHz, bi-directional without direction pin, with minimal passive components to get going. Issue is the package is not breadboard friendly so it was cheaper to get STM32 dev kit than ordering level shifting PCB. Once I get the PSU running for business I may come back to ESP32 as project and implement level shifting because it is still unclear to me why ESP32 would struggle with this task, bit banging with timing logic.

Nonetheless it is impressive how much thought qu1ck put into his project. Also trimmed display library with parallel interface where he writes via registers makes it very efficient. I managed to hit the limit with the i2c oled today   when pressing buttons fast my oled is freezing and the red light is on.  It seems not possible to write directly to memory of SSD1306 via i2c so I am getting also parallel interface oled to move on.

M.

[floobydust]

An Espressif guy mentioned it works with 5V input but was a bit leery about lifetime of the silicon as it's not tested up there.
There was no need to bit bang with the STM32 but yes with the ESP32? I also thought it could keep up but it does have a kernel and FreeRTOS in the background that might be the problem.

Do you have a running front panel board connected, while snooping the data stream? It sounded smashed up.
I ask because there is a watchdog between the front panel MCU and main CPU. No response from the FP causes the main CPU to issue a RESET (IGFPRES) and beep as well. I thought that could cause the glitch you kept seeing but no.

[mmx01]

I have the FP connected and sniff in parallel to the actual communication. Some buttons do work but overall its condition is as seen...



Since entire front is destroyed buying the shell with buttons, PCB and VFD would cost more than what I paid for the device. So my plan is to get this to a working state with oled and 3d print the front with likely new pcb with push buttons.

Encoder was also destroyed (in fact it split into two parts) but mechanically it turned out okay so I put it back together.

[trobbins]

iMo, did you progress with a simple and practical way to de-energise the display filament? 

I want to operate my meter for logging, and the display is showing some intensity variation, so I have some incentive to turn the display off as well as de-energise the filament - for the purpose of lowering internal temp rise, and prolonging useful service life of the display.  The assumption would be that de-energising the display filament has some correlation with display related failure/degradation. 

A concern could be if mains power is toggled, and the meter turns back on with display enabled (which I assume happens due to volatile memory), and that may add risk if the filament is otherwise switched off.   I guess a mains power latched contact could remove that risk.

[coromonadalix]

you could use the internal front rear switch lever / rod  to actuate a switch ? 

if you dont use the rear inputs,  a front rear movement could activate a filament switch ?  some push lock and push unlock  ??

just tie wrap something on the lever, but be careful not to damage it ?  they get slightly fragile on both end