Electronics > Repair
HP 34401a DMM with leaking segments
<< < (41/45) > >>
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:

--- Quote from: mmx01 on February 29, 2024, 07:28:37 pm ---With ESP32? Level shifting is not needed, IO is 5V tolerant.

--- End quote ---

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.
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