Pico different behaviour on Battery

Hello,

I had a look and couldn't find any info on this so any help would be appreciated.

I have a pico hooked up to two PIR sensors (and an eeprom) and everything works great. I wave my hand in front of one sensor, and I get a trigger, I wave my hand in front of the other, and I get a different trigger (using pins B1 and A7 indicating the signals with an LED flash). This great behaviour happens when plugged into the USB connector.

Things go wrong when I power it with an external battery (3xAA). Everything still works, except every time I trigger one sensor, it's LED and then immediately the other LED blinks indicating that both sensors have tripped. I've gone back and forth between USB and battery power many times and can replicate the behaviour consistently. I've tried different pins (A2 and A4), am running v1.79 of the firmware, and don't know what's going on.

Using batteries is key to my project. Has anyone else experienced differences in behaviour like this and can anyone give me clues as to what might be going on?

Strange - I guess one thought is that the PIRs may not behave as well off the slightly lower voltage?

Are you printing lots of text? When you disconnect from USB, Espruino swaps to Serial1 at 9600 baud on B6/B7 pins. If you print a lot then it could take a lot of time to finish, which could cause problems with the rest of your code.

Also, is everything grounded together? Sometimes people forget to make everything share the same GND, and the fact that GND comes from the PC sometimes makes it work when USB is connected, but fail when it's not.

If you have a USB-TTL converter handy, you can actually wire it up to GND, B6 and B7, and then connect to that with the Web IDE (at 9600 baud, which should be the default). It'll then let you to debug Espruino while it's running entirely off battery power, which might help?

Thanks for responding!

I've attached my circuit diagram because I don't think there are any issues there.

I'm not printing any text, but am writing to the eeprom at every event. I don't think that would cause an issue but you would know better than I.

Everything is grounded together, and all components are being powered by the pico's 3.3v VDD so there should be no difference in voltage when on battery vs USB. (The diagram is incorrect in that aspect, it indicates that I've wired the PIR's directly to BAT)

No USB-TTL converter handy unfortunately :(

IF you think of any other possibilities I'd greatly appreciate it!

1 Attachment

Ok, so the battery definitely goes to Bat, but the PIRs and EEPROM are connected to 3.3v?

Maybe check the 3.3v line and see what voltage is on it? If the batteries are NiCd then they'll be 1.2v, so 3.6v total, which may not be enough headroom to get reliable 3.3v....

... But if you continue to have problems, a USB-TTL converter would really help (and they're very cheap).

If you have a second Pico you could configure it as one too though.

I'm using Alkaline and have checked the 3.3v line, and it appears consistent.

I also hooked up a 5V power supply straight to the USB power and ground to see if there was something going on there, but same behaviour.

I do sometimes get good behaviour but other times I do not.

Is there a way to disable sleep mode? I'm wondering if that might be messing with it.

By default it's disabled, so I don't think that's your problem.

You could try using setInterval to blink a light every second, just to check everything is still working Ok

Are you referring to deep sleep as being disabled by default? I used setSleepIndicator(LED1) to watch the sleep pattern and it definitely went to snoozetown (which is awesome!) I just am not sure what else could explain the different behaviours.

On an entirely unrelated note that may be of interest to you: After sending code that had some behaviour which included lighting up LED's upon pin event (worked great), I removed the bit of code that lit up the LED's but left everything else unchanged, and sent it again, the LED behaviour was the same as for the original code despite that code being gone (incorrect behaviour). I then left the code unchanged, reflashed the Pico and then sent the code again, now no LED behaviour (correct behaviour). It seems that ghost code was surviving and being called somehow. Not sure if that's at all useful to you...

I also just wanted to say: Thanks for making the Pico! It's a blast and definitely makes trying new concepts quick and easy.

Yes, deep sleep would be disabled - I'd hope the normal sleep shouldn't cause you any problems with timing though as it still keeps the high speed clock running (including the SysTick timer - why the sleep indicator should blink ~4 times a second).

Have you tried attaching LEDs to each of the TTL outputs from the sensors while it's all in your circuit? It might help to narrow down whether both sensors actually are firing at the same time, or if it is a problem with Espruino. I guess you could also try just replacing both sensors with switches to see if you can replicate it?

I haven't seen this kind of thing before, so I'm more inclined to think it's some electrical issue (could be noise on the 3.3v line from Espruino suddenly doing some computation and turning on an LED?)

On an entirely unrelated note... ghost code

Is it possible that you unchecked Reset before send in the Web IDE Settings? That could cause you a whole world of pain, and may also explain some of the issues you're having?

You can check what code is currently in the Pico by typing dump() in the left hand side. It's not perfect as it has to reconstruct some things, but it should give you an idea whether you have what you expect or not.

On the subject of "ghost code" make sure you haven't created a reset function. I accidentally did this and then new code downloads were not replacing the code on the pico but adding to it!

I have also been experiencing some different behaviour on battery. A fairly simple blinking light program is running significantly faster on 4xAAA than on USB and on a CR2032 (for which the timing seems to be ok). Is that to be expected?

How are you connecting the battery? Are you connecting it to BAT_IN, or are you connecting it straight to Vcc (which will result in the board getting twice it's rated voltage, and would explain any weird behavior)

oops... yeah, I wasn't connecting to BAT_IN!

wow, ouch. Glad it's still working after that!

Next revision of the board's going to have better pin namings on it! :)

I'm amazed how the STM32 holds up so well to exceeding the 3.3v spec. I wonder if you could make a 5v Espruino like that :-P

Definitely - although it may not last for long :)

The STM32 is rated to 4v normally, so I guess it's not such a big stretch. Internally I think it runs at ~1.8v and has a voltage regulator, but I'd imagine at some point the GPIO or voltage regulator would start to have problems.

Strange about the low speed RC oscillator speeding up - it looks like it runs off 3.3v then ;) Probably explains why it's such a pain to get it to be accurate.