puck lite problems

I am using several (~35) puck lites to collect temperature data via external thermistors wired to pins 28, 30, and 31 following a similar procedure to your thermistor write up. I'm also advertising the data for live view capability. The thermistors are monitoring human skin temperature. Mostly they work fine and seem to be quite accurate.

The problem is, every day I use them I am losing about 2-3 pucks. They start reading bad temperatures, usually 5-10 deg. F higher than they should be, but sometimes 60 or more degrees off (which is a lot easier to spot!). When I disconnect the thermistor and check with a multimeter they frequently have low to very low impedance between pins 30 and 31 (the middle of the voltage divider and the low signal), but not always. I have not been successful in getting them to work again, at least without changing the circuit layout, and end up changing out the boards completely.

Another problem I see less frequently is the puck will completely crash for no apparent reason (it's more than a software reset - it loses its NRF advertising settings too). It's as if the battery died but it happens on fresh batteries and only an hour or so into logging/advertising. Often this will result in the bad measurements as above when I try to refresh them.

My best guess is static discharge is frying my boards but I'm really at a loss. Should I be using a capacitor to protect the ADC pin?

I'm using SR type probes from here: http://thermx.com/temperature_sensor_selection/Thermistor_Probes.htm

Thanks for any insight!

Static discharges could be an issue... capacitors can help, worst case you have to add 'transient arrestors'... but from your setup I would expect that nothing ever can touch the blank wires of your thermistor.

Sinc you do not show any code, it is difficult to make some comments about why a puck would completely crach. I could think of some issue in setTimout() / setInterVal() usage that could lead to buffer overruns. But that is a wild guess...

It would be difficult but not impossible to touch the bare wires. If the connector was partially removed it could be done. But a couple reset today that were happily chunking along with no indication of a problem. This time I was able to read the thermistors fine after reprogramming.

I have attached the code. Thanks for the help.

1 Attachment

• advertiser.js

It could be you're hitting issues because D28 is the default UART pin: https://www.espruino.com/Puck.js#pinout

There's a bit of a description at https://www.espruino.com/Puck.js#serial-console but basically if the Puck is powered on and it believes that pin D28 is pulled high, it thinks there is a serial port connected and it automatically swaps serial over to that (I think putting D28 in input-pullup mode).

So it could almost be intermittent depending in the temperature when the Puck boots (although since the other side of the thermistor is connected to an IO it's unlikely, and once booted that shouldn't change).

It is possible it's static discharge, but it does seem unlikely. For instance I have a Pixl (basically the same hardware as Puck.js) with 3 huge wires attached to the IOs with a DS18B20 sensor on the end and that's been running for years without issues.

Is the Puck itself running off a CR2032 and 100% disconnected from everything else? So it's literally just a Puck with 3 wires attached?

If for instance you had grounded the Puck then I could imagine RF interference might be an issue since you're basically attaching a big aerial to it. In some environments that could be forcing several volts into the IO pins. But the Puck is disconnected, since the 3 wires are all going to the same place it's hard to imagine there would be a different enough voltage between them if there is no other connection to it.

I notice those temp sensors have a metal washer on them for bolting to stuff - what are they bolted to? Could that have a high voltage on it?

Also, what happens on one of the 'dead' Pucks if you unsolder everything and run Puck.selfTest() on it?

The code you've posted there looks great, but some things that might help:

• When you're finished reading from the thermistor, make the analog input pin an output - which would make it far less likely there are voltage spikes on it:

  analogRead (D30); // <--- put D30 into analog in mode
  digitalWrite (D31,0);
  digitalWrite (D28,1);
  var val = 0;
  for (i=0;i<5;i++){
  val += analogRead (D30);
  }
  val /= 5;
  var ohms = 10000*val/(1-val); //or 10.88k measured on resistor before soldering to original puck (not puck lite)
  digitalWrite (D28,0);
  digitalWrite(D30,0); // <--- force D30 to 0
  

• Since D31 is always GND by the look of it, you could actually connect it to the GND pin instead. It might help with the stability of readings.

• The other thing you mention is the capacitors. While I wouldn't have thought they would be needed, they wouldn't hurt. And actually the analog inputs are supposed to be more accurate with a lower impedance - so having a capacitor between GND and the input might give you better temperature readings.

Also, totally unrelated, but did you spot the 'Puck.js Minimal' builds? Those strip out some features but give you more flash memory for storage which might help you out :)

The UART issue seems unlikely to me because the Pucks typically run for hours without problem beforehand.

The pucks are not grounded in any way, run from a CR2032, and the thermistor is actually the SR version (so no washer, it's a disc but with no hole) and is taped to a finger or toe. There are 2 wires leaving the puck, attached internally to a 2-way connector screwed onto the puck body. The thermistor connector mates with this.

I did the self test on a bad one, and got:
Pin D30 shorted low
Pin D31 forced low
Pin D31 shorted low
Error code L30
=false

I'm guessing this isn't good.

Thanks for doing that test - and that was with everything disconnected? so no resistors or anything on it? That would definitely seem to imply some kind of hardware failure if so.

they frequently have low to very low impedance between pins 30 and 31

Looks like the self-test backs this up too. Interestingly though it looks like D30/D31 may have ended up partially connected together as it seems like if D31 is floating, D30 can still read a value?

I just wanted to check - there's nothing like water damage that might have happened to the Puck? Salt water/sweat between the pins could explain something like this too.

What's the circuit?

• Sensor attached between D30 and D31
  
• Resistor from D28 to D30?
  
  

If you could switch to putting one since of the sensor directly on GND, I think that could help a great deal. As-is, any static electricity that makes its way along the wire is going to go right into the IO pins - and that could be causing the problems you're seeing I guess.

I did the test without anything connected and with the resistor still connected. When it was still connected, it looked pretty much the same but it also said:
"LED2 pullup voltage out of range (0.542...) - disconnected?"
and error code was LD2, not L30

The LED still worked when I set it high.

Looks like the self-test backs this up too. Interestingly though it looks like D30/D31 may have ended up partially connected together as it seems like if D31 is floating, D30 can still read a value?

I'm not sure exactly what you mean here. D30 reads ~0, but with everything disconnected I'd expect that. Do you mean for me to try this on a board that hasn't been desoldered?

The circuit is as you described. For future versions I will put one side on ground. As far as water/sweat damage, I can't rule it out but it seems unlikely. I will try to get a picture of one of the setups posted.

Hmm, that's interesting!

"LED2 pullup voltage out of range (0.542...) - disconnected?"

This can happen because the battery voltage is low... Have you tried measuring it, or maybe running E.getBattery() and seeing what it reports?

That could explain your temperature readings being off - if the voltage was starting to get very low then it would easily cause the readings to drift off substantially!

I did the test without anything connected and with the resistor still connected

Ok - in this case, I think you can ignore the error about D30. That was basically just reporting that it thinks that D30 was connected to something (which is was - a resistor).

I guess D31 could still be an issue though...

But I'd say as a first port of call, check the batteries out - it would make a huge amount of sense given what you're seeing.

It's possible the battery was low for the self test, because for this type of bench check I tend to use any old battery laying on my desk. But in the field I try to use fresh batteries, and I actually find E.getBattery to be too coarse of a measurement to monitor their condition. If I use them to the point E.getBattery reads anything below 100% I start seeing power failures. I think this is due to the full power advertising I'm doing. And the field measurements are sometimes taking place in a very cold environment, which doesn't help battery capacity.

I instead run NRF.getBattery each time I program them for a mission, and I strongly consider replacing batteries if it reads less than 3 V. At this point (and well below it) E.getBattery still reads 100.

Also, I only saw the LED message when the resistor was still connected from D28 to D30. When I cut it that went away, but I still had both D30 and D31 errors. Yesterday I tested several other failed pucks and got similar D30/31 errors. Can you point me to the code the self test runs?

Ok, that's a shame - it would have been a good fix!

Yes, the self-test code is https://github.com/espruino/Espruino/blob/master/libs/puckjs/jswrap_puck.c#L1325-L1371

Changing the software even to just leave D30 forced to an output, are you still seeing as many failures?

Hi Gordon, I haven't been needing to use these for the past week or so, so I haven't made the code change. I could do a handful of them and let them chunk away, but I don't have time to deal with all 35 of them at the moment. Do you think that would be worthwhile?

Hi, I think before you next deploy them, making the code change would be very worthwhile. It just adds an extra bit of protection for the input pin when it's not actively being sampled, which has really got to help.

Of course if it were possible to make the hardware mods suggested I imagine that would totally fix it