Giter Site home page Giter Site logo

Comments (20)

serisman avatar serisman commented on August 9, 2024

Wow... you built that PCB pretty fast! I just designed the board this morning.

No, I haven't actually tested this on the PMS150C yet. I was going to wait until I get my PCBs back in about two weeks. I also don't have a good way to program the SOT23-6 yet (waiting on delivery of an adapter module). I suppose I can try with the SOP-8 version in the meanwhile.

I will dig through the code and see if I can find what might be wrong.

from pdk-continuity-tester.

serisman avatar serisman commented on August 9, 2024

Well there was a typo in hal.h on line 20 that meant the wrong defines were used. I'll push up a fix. Maybe it was that simple?

from pdk-continuity-tester.

serisman avatar serisman commented on August 9, 2024

Ok, I can confirm that it is working properly on a 6-pin PMS150C (after the fix on line 20 of hal.h).

The only difference I found so far, is that the buzzer is operating at a much higher pitch (about 8 kHz instead of 2 kHz). I'll have to dig into the PWM values again.

from pdk-continuity-tester.

kaweksl avatar kaweksl commented on August 9, 2024

Wow... you built that PCB pretty fast! I just designed the board this morning.

Design is small, uses mostly 1 layer, for that i have fast method. Photosensitive film + DLP 3D printer, 10 min. work + 1h waiting,

The only difference I found so far, is that the buzzer is operating at a much higher pitch (about 8 kHz instead of 2 kHz). I'll have to dig into the PWM values again.

Almost works :)
Looks like pwm freq is ~8kHz but duty cycle is minimum (1 timers cycle ?)

from pdk-continuity-tester.

serisman avatar serisman commented on August 9, 2024

Wow... you built that PCB pretty fast! I just designed the board this morning.

Design is small, uses mostly 1 layer, for that i have fast method. Photosensitive film + DLP 3D printer, 10 min. work + 1h waiting,

👍 I guess I didn't even notice that this is mostly 1 layer and could easily be done with home equipment. Honestly, I haven't make PCB at home in years. I find it too much hassle for the end result. Online PCB shops are so cheap and good quality these days. Just have to wait for delivery.

The only difference I found so far, is that the buzzer is operating at a much higher pitch (about 8 kHz instead of 2 kHz). I'll have to dig into the PWM values again.

Almost works :)
Looks like pwm freq is ~8kHz but duty cycle is minimum (1 timers cycle ?)

Yeah, I guess I should have read the datasheet in more detail. My PWM values were all wrong. I will check in some better PWM code soon. Just doing some final testing.

from pdk-continuity-tester.

kaweksl avatar kaweksl commented on August 9, 2024

Hmm also it turns off even if probe is constantly shorted to ground.
I don't see 8kHz with 50% duty either.
Maybe pin change wakes up uC but comparator is not detecting anything and uC goes to sleep again ?.

from pdk-continuity-tester.

serisman avatar serisman commented on August 9, 2024

Hmm also it turns off even if probe is constantly shorted to ground.
I don't see 8kHz with 50% duty either.
Maybe pin change wakes up uC but comparator is not detecting anything and uC goes to sleep again ?.

What voltage are you using? I am noticing something similar on my PFS173 with anything over about 3.3V. But, it seems correct at 3ish V.

from pdk-continuity-tester.

kaweksl avatar kaweksl commented on August 9, 2024

Powered with bench psu at 3V, now also tried with cr2032, same thing

from pdk-continuity-tester.

serisman avatar serisman commented on August 9, 2024

I just pushed some new code that fixes the PWM issues. Can you give that a try?

Which IC are you currently testing with?

from pdk-continuity-tester.

kaweksl avatar kaweksl commented on August 9, 2024

PMS150C-u6

from pdk-continuity-tester.

serisman avatar serisman commented on August 9, 2024

Ok, weird. I am not seeing that issue.

I just tested my PFS154 and PMW150C-U06, and they both work fine with any voltage from about 2 up to about 5. I can hold the probes together and it will stay on until shortly after I separate them.

I do still have a weird issue with my PFS173 where it isn't working over about 3.3V, but seems to work fine between 2 up to about 3.2. Maybe it is a bad IC, or maybe I'll have to dig through the datasheet more tomorrow to see if there is anything different about it.

FYI... signing off for the night (2:40 AM here).

from pdk-continuity-tester.

kaweksl avatar kaweksl commented on August 9, 2024

Shouldn't we calibrate bandgap ?

EDIT:
Now i'm testing on PFS154 and i have two chips that works only above 4V

Edit:
another PFS154 not working like it should, works below 2.2V
despite calibration

EDIT:
Ok don't need to calibrate BG because we don't use it, maybe we should ?

I think pull-ups differ from chip to chip very much, as they are weak pmos, not resistors

from pdk-continuity-tester.

serisman avatar serisman commented on August 9, 2024

Shouldn't we calibrate bandgap ?

Maybe, but I don't think this actually uses the bandgap.

EDIT:
Now i'm testing on PFS154 and i have two chips that works only above 4V

Edit:
another PFS154 not working like it should, works below 2.2V
despite calibration

Ok, weird. I'll have to do some additional testing with different chips myself.

EDIT:
Ok don't need to calibrate BG because we don't use it, maybe we should ?

Maybe. How do you envision using it?

I think pull-ups differ from chip to chip very much, as they are weak pmos, not resistors

Interesting. Maybe we should try with external pull ups then. According to the original article ~50k (i.e. 47k) would be a good value to try.

from pdk-continuity-tester.

serisman avatar serisman commented on August 9, 2024

I just tried using external 47k resistors on the Reference and Probe pins (Comp+ and Comp-), after commenting out the PAHP lines in the source code. That seems to have fixed the weirdness I was seeing with the PFS173.

The downsides are two additional components, but more importantly, the idle power consumption increased dramatically because we have no way of turning off the external pull-up on the Reference pin (so there is always a 47k load). I measured an idle power consumption increase from around 0.2 (+/- .1) uA up to 40-100 uA (depending on VDD). That means a few weeks to months of idle time instead of many years.

I'll try some more tests later on when I have more free time. Maybe higher value resistors would work just as well, and cause less idle power consumption.

from pdk-continuity-tester.

serisman avatar serisman commented on August 9, 2024

Another thought, although untested... we might be able to re-arrange the circuit a bit to pull-up the Reference and Probe lines to the 'power' LED, instead of pulling them up to VDD. That way, no current would flow when the LED/MCU is off. This would require changing the LED to be active high (source) instead of active low (sink). Might still need an internal pull-up on Probe to still allow wake-up from sleep. I'll have to think about this more.

from pdk-continuity-tester.

serisman avatar serisman commented on August 9, 2024

Did some more research and thinking on the subject, and have the following additional observations:

  1. The Padauk datasheets list a Comparator Offset of +/- 10-20 mV. So there can be a fairly big difference between ICs.

  2. The Padauk datasheets specify a pull-high resistance of approx 200k -> 600k (in the 3.3v -> 2v range) for the PFS154 and PMS150C chips, but only 150k -> 400k for the PFS173. Either way, this is way higher than the ATtiny85's 20k - 50k.

  3. The original circuit was build around a 50 ohm / ~50k ohm voltage divider for the reference, which means about 5mV at 5v. We are using higher pull-ups and lower voltage, say 200k ohm and 3v, which is only 1mV reference. Not sure how that interacts with the Comparator Offset that may be significantly more than our reference voltage. We could increase the 50 ohm resistor to compensate, but that would mean we would trigger on higher resistances as well. Or, we could decrease the pull-up resistor, but then we have to solve the idle power consumption issue. This may also mean we are allowing more current to pass through the probes, as well.

from pdk-continuity-tester.

kaweksl avatar kaweksl commented on August 9, 2024

Making externally switchable pull-up might work but sadly PA5 is open drain only, and can source current only thru its pull-up :/ , Maybe it would be possible to make permanent pull-up on reference pin and switchable low resistor ?.
Or maybe swap PA6 and PA5. I'm not sure if PA5 have wake-up.
External pull-up on probe shouldn't take power while not operating.

Maybe, but I don't think this actually uses the bandgap.

No idea, I was loosely thinking there :P

from pdk-continuity-tester.

serisman avatar serisman commented on August 9, 2024

Making externally switchable pull-up might work but sadly PA5 is open drain only, and can source current only thru its pull-up :/

Yeah, I was thinking of the PFS154/PFS173 when I was thinking about that, where the LED is on PA6. But, I agree, that won't work on the PMS150C where the LED is on PA5.

, Maybe it would be possible to make permanent pull-up on reference pin and switchable low resistor ?.

Maybe, not sure at the moment.

Or maybe swap PA6 and PA5. I'm not sure if PA5 have wake-up.

We can't really swap PA6/PA5, at least if we want 6-pin compatibility. The reference has to be on the COMP+ pin which is PA4. For the PFS1xxx, the probe has to be on a COMP- pin, which means PA3, meaning the Buzzer has to be on PA5 which is the only other available PWM, leaving PA6 for the LED. For the PMS150C, the only available PWM for the buzzer is PA3, meaning PA6 has to be probe (because it requires COMP-), and that only leaves PA5 for the LED.

External pull-up on probe shouldn't take power while not operating.

Yeah, the probe doesn't matter. The issue is with the Reference because it has the voltage divider that always consumes power unless you can remove one side from the equation.

from pdk-continuity-tester.

serisman avatar serisman commented on August 9, 2024

Ok, another option...

We can use the internal voltage reference, instead of creating our own.

https://github.com/serisman/pdk-continuity-tester/compare/feature/VintR?expand=1

Using GPCS, we can set VintR to a minimum of 1/32 * VDD, which means ~94 mV @ 3v. This frees up the COMP+ pin (PA4) for other uses as well, and may mean we could now have a consistent set of pins across all devices.

To maintain a 50 ohm threshold/sensitivity, we would install an external ~1.5k pull-up resistor on the probe pin, instead of using the internal pull-up.

Doing it this way solves the comparator offset/variance issues as well as the idle power consumption issues, but does have a downside that we have increased the current that passes through the probe to about ~1.875 mA.

Since most multimeters use around 1mA, it might be better to increase the sensitivity up to 100 ohm (by using ~3.1k pull-up) which decreases the current down to ~0.9375mA.

So, not as good as the 50 ohm / 0.1 uA of the original design, but at least as good as most multimeters.

EDIT: This is tested working on my weird PFS173.

from pdk-continuity-tester.

serisman avatar serisman commented on August 9, 2024

It's only been 2 1/2 years, but I finally picked this project back up and made a decision on how to fix the issue caused by the weak internal pull-up resistors.

After re-considering all the options, I felt that external pull-up resistors was the best of the available options. In order to keep the low power consumption when sleeping, this means connecting one of them to an output pin (instead of directly to VDD). This allows us to switch it off before entering sleep mode, thereby eliminating the constant drain. This required an extra pin than the 6-pin ICs had available, so I just consolidated everything to a new single 8-pin design.

The old code/schematics/pcbs are still in a branch (old-vesion), but I don't intend to touch them further.

from pdk-continuity-tester.

Related Issues (1)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.