Forum Replies Created
-
Posts
-
Hi Phang Moh,
Looking at the battery technical description, it does appear they don’t have short-circuit protection 🙁 which makes sense based on the datasheet link you posted. I returned these batteries and got some that do have short-circuit protection, however I probably need to update the application on the device to either initiate charging when the battery voltage goes down to a certain level, or just have a way to cut power off after a last uplink message notifying low battery (if charging source isn’t in place).
Thanks,
Amir.The device finally stopped transmitting after 14431 uplinks (almost 2x my minimum requirement). Voltage had dropped around 1.8v before I plugged the USB power to recharge.
The LED behavior is still weird. When I plugged in the USB cable, both the green and the red LEDs turned on which I was expecting. However the red LED turned off almost immediately (it was just a quick blink) and it’s not on, although I can see the battery voltage is going up steadily as it is recharging. I was expecting the red LED to stay on until battery is fully charged. So I am not sure what is going on there.
The device has performed, really well though and I am sure some more optimizations can be done in the code to make battery last a little longer.Amir.
Hi Phang Moh,
You are right, the BH1750 will continue to draw current in sleep mode unless there is no light and it looks like most sensors behave that way. I have a couple of TEMT6000 breakout boards, so I gave them a try. I am actually surprised, in that configuration I get between 20-30uA which is very good.deviceName:"microsense-device-hub-002" fCnt:3171 fPort:1 battery:3.68 humidity:55 light:14 pressure:1010 temperature:25So in near ideal conditions, after 3171 uplink messages, the battery has 3.68v. At the start of the test it was at 3.79v. So this looks very good. Of course, in real conditions things are going to be different, but this gives me a very good base to work with.
Thanks again for the great suggestions.
Amir.I am having an issue with one of the board. I don’t get any serial unless the battery is plugged in (i.e the port does not show up on my mac). I loaded the board with LED blink script (it blinks every 5 seconds).
The script runs fine when the board is powered by the battery alone and continues to work when I plug in the USB while it is powered with the battery.
And the strange thing is the board is getting power through the USB, I measured 5.05v. But if I remove the battery, the script stops.
There is no low power involve, just the basic LED script.When I plug in just the USB cable, the green LED turns on and then off and remains off.
Any ideas what is going on?Not all devices are low power.
This made be go back and review my code a little more carefully 😉
Currently I have a BME280 and a BH1750. The BME280 is set to go sleep after each measurement. But I found out the BH1750 was set to continuous mode high resolution rather than one shot which kept IC2 interface active during sleep cycle. I corrected the code and I am now seeing 340uA. It’s much better, but still about 10x more than what I would expect.
I also found there was a Serial print done after the flush, so probably contributed as well.I am inserting the multimeter between the battery and the 3v3, so I am not sure this a good place for measuring what the board as whole is consuming.
Also right now the sleep cycle is 30 seconds for testing as I want to see how fast the battery will die.
That’s exactly what I am doing. It’s on when the radio is on to transmit and then off when in standby. That way I can also tell when data is being sent. I haven’t taken any measurement, but the sleep/wake cycle seems to be working as expected.
I am not using the LowPower library, though. Just using the RTC library like in the tutorial. I am not sure the standby API from the library is working the same way for the SAMD21.
Yes. That did it! After shorting the connections for both RST and DIO1 the board is now consistently joining successfully.
Well, really appreciate the help (and the patience) with this. I can safely say the boards have been validated to work as expected, except for that LED light staying on on one of them. But it doesn’t seem to affect any operations.I am now eager to update my LMIC sketch to use the low power mode. I’ll take a closer look at the tutorial for that.
Thanks again for that bit of hand holding 🙂As a quick (and dirty) experiment, I commented out the ASSERT and the device eventually joined
09:44:58.149 -> [do_send] Packet queued 09:44:58.149 -> EV_JOINING 09:44:58.149 -> EV_TXSTART 09:44:58.892 -> EV_TXSTART 09:45:06.551 -> EV_TXSTART 09:45:08.216 -> EV_TXSTART 09:45:18.271 -> EV_TXSTART 09:45:25.227 -> EV_TXSTART 09:45:30.248 -> EV_JOINED 09:45:30.248 -> netid: 0 09:45:30.248 -> devaddr: 83FB40 09:45:30.248 -> appSessionKey: 651336BA162C8C845A17F578FACAF0 09:45:30.248 -> netSessiomKey: 54A84A2189EC1AFAA18E187547745994 09:45:30.248 -> sequence up: 0 09:45:30.248 -> sequence dn: 0 09:45:30.248 -> 09:45:30.248 -> EV_TXSTART 09:45:31.290 -> EV_TXCOMPLETE Done Sending data (includes waiting for RX windows)Note that the joine took a long time, so timing seems to affect the reliability of success when the DIO1 Jumper is opened.
Now here is a very basic question (I am not a hardware engineer). How do I short that DIO1? Do I just solder the pins together. Or maybe try to solder a jumper, so it’s configurable?
The code I am using is proven to work as expected and I already adapted it based on the tutorial. It’s working perfectly on one of the board.
But I added DEBUG to LMIC (also had to redefine Serial to SerialUSB in the config and it is throwing an Assert because the Radio went to sleep after sending the join request.
09:33:42.503 -> EV_JOINING 09:33:42.503 -> EV_TXSTART 09:33:42.538 -> FAILURE 09:33:42.538 -> /Users/anathoo/Documents/Arduino/libraries/MCCI_LoRaWAN_LMIC_library/src/lmic/radio.c:746static void startrx (u1_t rxmode) { ASSERT( (readReg(RegOpMode) & OPMODE_MASK) == OPMODE_SLEEP ); if(getSf(LMIC.rps) == FSK) { // FSK modem rxfsk(rxmode); } else { // LoRa modem rxlora(rxmode); } // the radio will go back to STANDBY mode as soon as the RX is finished // or timed out, and the corresponding IRQ will inform us about completion. }It’s failing here:
ASSERT( (readReg(RegOpMode) & OPMODE_MASK) == OPMODE_SLEEP );
This seems to confirm what you were saying about shorting the DIO1 jumper, correct?
But why this would only affect this one particular board and not the other?Is the DIO1 jumper at the back of the board shorted?
I haven’t shortened the jumper. The odd thing is again the second board working as expected and it’s not altered either.
I tested the boards with the same antenna and with only 1 device connected at a time. The gateway is about 12 meters away and separated by a ceiling.
As far as I can tell the join request isn’t being received by the gateway and the board is basically stuck waiting for a response. I’ll enable LMIC debug tomorrow (it’s late here) and report my findings.I loaded the blink code and it’s fine. It blinks on/off
23:52:12.969 -> LED OFF.... 23:52:12.969 -> LED ON.... 23:52:12.969 -> LED OFF.... 23:52:12.969 -> LED ON....However I do get the following error very frequently and I have to push the reset button. It takes sometimes 2~3 attempts to load the code.
Sketch uses 11676 bytes (4%) of program storage space. Maximum is 262144 bytes. Forcing reset using 1200bps open/close on port /dev/cu.usbmodem14201Regarding the loraWan join, I am using an already defined DEVEUI which is already added to the Network Server (I am using loraserver.io). I know the code works, because the second Ultra Pro loaded with the same code is working perfectly.
Here is a partial log
23:57:56.957 -> HUB-001 STARTING... 23:57:56.957 -> LMIC: Initializing... 23:57:56.991 -> LMIC: Reseting... 23:57:56.991 -> LMIC: Starting OTAA... 23:57:56.991 -> [do_send] Get sensor data... 23:57:56.991 -> ============================ 23:57:56.991 -> T = -15 *C 23:57:56.991 -> H = 45 % 23:57:56.991 -> P = 1012 hPa 23:57:56.991 -> M = 75 % 23:57:56.991 -> G = -17 *C 23:57:56.991 -> L = 55245 lux 23:57:56.991 -> ============================ 23:57:56.991 -> [do_send] Packet queued 23:57:56.991 -> EV_JOINING 23:57:56.991 -> EV_TXSTARTDon’t pay attention to the data, they are bogus for now 🙂
And what seems to be happening is the Join request isn’t being received by the gateway at all.
