Most recent activity
-
I missed @AkosLukacs post, but LiFePO4 looks good - and it may be ok with being trickle charged via a solar cell even without a charge circuit? you'd have to check the datasheet.
Other potentially more resilient cell chemistries are available too - for instance https://www.sii.co.jp/en/me/datasheets/ms-rechargeable/ms621fe/
-
I should add that even if a normal CR2032 would struggle to supply the current needed, you could add a decent capacitor to help somewhat.
-
My general take on this is: If you're modifying C source files or otherwise making big changes, you're more than capable of setting up a dev environment (which with 'Bash on Windows' or Linux is basically copy/pasting one command in a terminal). In fact trying to compile and debug your code using a web compiler would be amazingly slow, painful and frustrating, plus you'd waste loads of CPU time on @JumJum's server (which he's providing for free) doing hundreds of builds.
On the other hand, if you want a custom build with some modules built-in, or you need to disable something and enable something else, EFEU is really nice to use and way faster than doing your own dev environment.
-
I think given the size of the cell it's not going to provide a bunch of power, so really you want one that provides enough voltage to charge the battery directly, rather than with a step-up converter.
A few things come to mind:
- Use an off the shelf solar power bank like this one - the 5v output may draw too much power to use consistently so you may need to crack it open and connect to the LiPo directly.
- As others have said, charging a LiPo from a solar cell is a bit iffy. However if you're using a LiPo with protection circuitry in it then you might be ok, especially if the cell is small so doesn't provide much power. I actually have some devices here where I do exactly that, but I couldn't recommend it for a product.
- You could use a Puck.js with a LiPo CR2032 cell, and a trace cut on the board and diode added as I mentioned in your other post (because otherwise the voltage is too high). There's no cell protection circuitry on those so I'd recommend you use a 3.9v zener diode (the closest zener voltage below 4.2v) to stop overcharging. It'll work and be safe, but I'm not convinced about the cell lifetime.
- NiMH cells are probably a good bet for this kind of thing as mentioned previously.
- You could use a supercapacitor, which should have a very long life. You just need to be sure to choose one that doesn't have a high self-discharge rate. Trying to get one that'll fit in a Puck.js form factor could be difficult.
However with all the battery based solutions (so not supercapacitor) the batteries have a lifetime - they'll only work for a certain number of charge/discharge cycles or amount of time.
If you just stuck a non-rechargeable Lithium AA cell in the box then that'd provide over 2500mAh and a 10 year life, and with simple advertising would probably outlast most of the other solutions, without needing daylight.
- Use an off the shelf solar power bank like this one - the 5v output may draw too much power to use consistently so you may need to crack it open and connect to the LiPo directly.
-
I'm afraid I don't - I think for pretty much any motor you'll need an or FET/transistor to turn it on based on the GPIO. However the CR2032 batteries really aren't designed to provide that amount of power, so even if you do get it working it'll reduce battery life quite a bit.
Having said that you can get LiPo CR2032s, and while you can't use them directly because of the increased voltage, the Pucks actually have an area where you can cut a wire trace and solder on a diode, which will drop the battery voltage by enough to use it.
-
Maybe @JumJum could provide some ideas? the
BLACKLIST.jsonis his addition to the build system.You could always check out his EFEU project and see what it writes into the blacklist file.
-
Wow, that's great - thanks! Just searched through and there's a bunch of interesting stuff in there!
The H808/DK08 (same watch?) look particularly good with a reasonably big 176x176 screen. Still no full touch by the look of it.
If I don't have any success going to the manufacturer (some of the newer ones seem to have nice high-res screens and a proper touchscreen) then those definitely look like the best bet.
-
I believe the blacklist entries get removed from
gen/jswrapper.c(you can check that file easily) - they then won't be referenced and should be optimised out.But I wonder if you're compiling with
RELEASE=1? If not the optimisations may not happen
Are you sure the code posted right at the beginning is the only code running on your device?
That error corresponds to
BLE_ERROR_GAP_INVALID_BLE_ADDRwhich is described as:It seems possible that your TELO 580 is reporting itself with an invalid Bluetooth LE MAC address.
Please could you tell me what the MAC address the
nRF Connectapp reports the TELO 580 as is?