Search results for:

Am I safe removing e.g. the health app programmatically?

code snippet:
var files = require("Storage").list();
files.forEach(function(element){
if(element.startsWith("health") ) require("Storage").erase(element);
});

The reason I ask is I'm managing ~50 Bangles and I'd like to do this with Node instead of running the app loader on all of them. This is on Bangle.js2 if it makes a difference.

Thanks in advance!
Dan Fox

It happens when I'm connected via the IDE and without - doesn't seem to make a difference. I had already tried various connection intervals, but the Core says it wants between 7.5 and 100 ms, and also longer intervals just seemed to make it ultimately take even longer to reconnect because I found I had to adjust the checkConnectivity interval up to account for the longer timeouts. I have tried a couple 2021-Q1's and a 2022-Q4 Core. It doesn't seem to make a difference.

But I did notice that the 2022-Q4 Cores support multiple connections. So I tried the following with 2 Bangles: I set one up with the latest firmware and standard power (0 presumably), and the other was using 2v19.10 (the version I'd been using before) and TxPower 8. Both connected to the same HRM and Core. I ran it a few nights and the higher power one was noticeably better overall. The new fw might have helped a bit too, but it's difficult to tell with the data I've collected so far. I will make both changes going forward, though. I wouldn't have thought the power level would make that much difference, the range is less than 1 meter at all times since I'm wearing both devices. The pucks were in another room and still read pretty well. So thanks for the suggestion!

I'm trying to persistently connect to 2 BLE devices: a Core temperature sensor and a generic HRM. In addition, I need to read advertising (as manufacturer data) from 2 pucks set up to read thermistors. And do sleep measurement similar to sleeplog. All of the temperature data plus heartrate will also be advertised as manufacturer data from the Bangle.

The problem I'm having is with the Core sensors. They frequently disconnect and I can't figure out why. I am still able to connect to them with nRF Connect when this happens. Sometimes they are good for an hour or so, but more often than not they disconnect several times an hour/minute and may take several minutes to reconnect. I have tried several cores with the same result. I have also (separately) tried using the Bangle coretemp app with recorder set to a 10 second log rate and run for over 14 hours without seeing any loss of core data. This is only a single connection though.

The HRM has no such issues. If the connection there is lost while the HRM is still powered and in range, the connection is generally remade on the first try.

The general idea is first the program connects to the HRM, then the Core, then it starts scanning for advertisements and checking both connections every 10 seconds to ensure they're still up. I've prioritized reconnecting to the HRM first, mainly because it's typically much more reliable. I have tried to ensure that each device locks the other out of connecting while it's trying to, and that I am not scanning for ads during this time. My code is attached, apologies in advance for the length. I have also included a snippet of the data that I've collected including some errors I was able to log. On very rare occasion I've also seen uncaught errors such as "Uncaught InternalError: BLE task completed that wasn't scheduled (SERVICE/NONE)".

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?

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?

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.

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.

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.

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!