Forum Replies Created
-
Posts
-
Hi Brian,
Sorry, we just came back from China and went a bit under the weather this morning.For external interrupt that requires direction (falling, rising), please use the extended external pin interrupt for the SAMD21 core as it is not supported directly under the Arduino SAMD21 core. Not sure why the Arduino team decided not to add them into the main line. Using that library also means you don’t need any other RTC and sleeping library as they are incorporated inside it.
For the USB portion, I don’t see any proper USBDevice.detach(); USBDevice.init(); or USBDevice.attach(); in your code. Please take a look at the code in this documentation section on how it is properly implemented.
I doubt that you can run away from putting the receiver in receiving mode all the time to receive the packet.
As the event is non-deterministic, and even if the time synchronized (I believe the Series 1 has this firmware capability) is used, it is very hard for you to get the message across successfully let alone at single try.Why do you need wireless when there’s only 2 feet? It is because one is external of the building? And another is inside?
The PIR sensor can also work on it’s own without any external MCU and can show lit up an LED when there’s a motion. You probably just need to wire the LED for 2 feet if that is where you want it to be.
Hi,
An XBee user here back in 2006! You can use the 3.3V to power the XBee itself. The Pro version of the XBee is 215 mA but could still work with the on-board 3.3V regulator as the transmission is quite fast. If current is inadequate, add an external 3.3V regulator by tapping from the VBUS power.The XBee is basically a 3.3V device so you could connect them directly with the Mini Ultra Pro. Use either Serial or Serial1 to connect the UART up.
The PIR sensor should trigger when there’s a motion only, so you could use an interrupt to wake the MCU up and then MCU will wake the XBee for transmission. There are many PIR sensor out there but some could go down to 6 uA. If the XBee is properly put down to sleep and coupled with a low power PIR sensor and suitable battery capacity, you could run for more than 1 year.
Hi antapc,
Thank you for posting your findings here. Although my understanding is SysTick would not be running during standby/sleep, leaving only the RTC to run. Unless there is a possible race condition upon waking up that locks the board up.
Hi Amir,
If you look at the BQ24074 datasheet on page 11, if your battery voltage is very low (in your case, 1.8V), it goes into a mode called battery short circuit detection before actually moving into pre-charge mode. In this mode, the red charging LED shouldn’t lit up. You shouldn’t drain a Li-Ion/Li-Pol below 2.7V. It will damage the battery in the long run. Most battery pack has an automatic cut-off switch to prevent this from happening but some doesn’t have.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.
Please take a careful look at the sensor datasheet. The sleep current of BH1750 only holds if the light lux is zero (total darkness). Else it will go up whenever light is present. As far as from my experience, only TEMT6000 are able to operate in very low current even when light is present.
Multi-meter should be used between battery + terminal and VBAT pin terminal (either the breakout pin or JST 2.0mm connector). What you are doing will damage the board as you are applying VBAT directly to the 3.3V rail.
1. When I power the board both with USB and the Battery (from the provided connectors), my understanding is the battery will get charged until it reaches 4.2v and while it is being charged, the board is drawing current from the USB power. Is this correct?
Correct.
2. What is the LED behavior? My understanding is the following:
When both sources are used:
GREEN Led always on when within 5-10.5v
RED Led when charging on, then off after being charge is complete.
When only battery is used:
Both LEDs are off
Additionally the GREEN Led will turn off if the board is supplied more than 10.5V
Is this correct?Correct.
3. Now I am very confused as to what the different power PINs mean and their typical usage. Specifically I want to know what pin should be providing power to sensors when the board is power with either USB or the battery. I don’t know if different pin should be used, or not.
My assumption is that I should use the 3v3 pin in both configurations (USB teetered and standalone battery), all my sensors are operating at that level. Is that correct, or should I instead draw power from the Vin PIN in all cases?Depending on your sensor requirement, you could tap the power from different pins. If your sensor requires 3.3V, then use the 3.3V. The 3.3V can source up to 250 mA but bear in mind that the radio and the rest of the board components also uses that, so please make sure sensor power requirement is not over that. When not using the 3.3V pin, you could also add external regulator by taking power from the VBUS pin. VBUS pin the recommended pin to further derived whatever power rail you want (VBUS maximum is 4.4V) by using it with conjunction with an additional suitable regulator. The rest of the power pin might not be available depending on the scenario. For example, if VIN takes in power from solar, it is not a recommended place to tap the power. VUSB (5V) is also not always present. So, the best place is to use VBUS or 3.3V.
The LMIC automatically sleeps the RFM95W when not in use. You don’t have to add anything extra.
I have 2 sensors connected to IC2 interface. I am assuming these should automatically go into sleep when the MCU is in standby. So I am not totally sure what else I may be missing.
Never ever assume that. What devices are these? Not all devices are low power.
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.
RTC library is enough. The LowPower library support was written by me prior before they implemented the sleep functionality to the RTC library.
No problem Amir, glad to help.
You should drive the LED to a known state else it would be floating. For low power, turn it off (active low).
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?The LMIC has always been using the DIO1 to check the state of the transceiver. As the pin is not shorted to DIO1, it could be floating.
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?
Please take a look at this image for shorting the connection. A blob of solder will short it easily.
Take a look at the tutorial here. Although it is for TTN, the hardware setup is valid for any LoRaWAN server.
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.
For more consistent uploading, double press the reset button in quick succession after pressing the upload button. The upload process is a bit inconsistent due to the timing and it happens with the SAMD21 bootloader unfortunately.
Is the DIO1 jumper at the back of the board shorted? We need that to be shorted so the LMIC can check the pin when it is waiting for a response. The radio was also tested (but without the DIO1 pin shorted) and verified working during production.
There are a host of other possible reason like boards are too near the gateway or antenna frequency mismatch.Are you able to enable further debugging on the LMIC section (must be enable from LMIC header file)? We might be able to see what is wrong there.
Amir,
It looks very likely your code is not uploaded onto the board? The behaviour suggested this possible cause. Can you load a simple Blink code? All IO pins are tested during production including the LED, so I doubt that is the issue.Also, make sure your DEVEUI is correctly loaded on the TTN dashboard.
