We’ve added two new LoRa/LoRaWAN Asset Trackers to our insect zoo of end devices.
First is the long Cricket, 81 mm x 23 mm and needs no external antennas.
Second is the Gnat, 20 mm x 20 mm–as small as a US 5 cent piece.
Both are designed for ultra-low-power (~2 uA sleep current) while continuosly monitoring the state of device motion. Both offer one-year operation on an AA-sized 3.6 V LiSOCl2 battery (average usage with 2-hour fix and 10 min LoRaWAN update duty cycle is 250 uA).
If there is a smaller LoRaWAN asset tracker than Gnat or a lower power LoRaWAN asset tracker than either I have yet to see it.
A few clients historically have had problems doing designs with chip ants like this (gain & tuning) with poor effectiveness, glad to hear you seem to be doing ok with it. What gain figure are you seeing? VSWR @868Mhz? etc. Have you done range tests at a distance to validate against the two GW’s you mentioned?
Haven’t done any formal measurements, relying on the data sheet for typical gain. We have done informal range testing. We see at least 500 meters at US915 MHz and up to 1.4 km at 868 MHz.
From the Grasshopper page (same antenna design):
" Initial tests show reception out to 150 meters with no direct line of sight (through houses and cars, etc) and >500 meters out in the open. One report shows reception at a 30 meter tower antenna 1.4 km away with RSSI -115 and SNR of -9."
So not too bad for a little chip antenna!
My own range tests have shown good reception to the MTCAP gateway from ~0 to ~350 meters with US915 MHz (no missing data), which is as far as I can conveniently go. This is plenty good for my use on my two acres…
I have been impressed by your previous LoRaWAN-devices, they have been perfect for my prototypes. I am glad you are going further and looking forward to testing them out. Keep up the good work!
Hi @onehorse, both devices look amazing - great selection of components! I have few questions:
What’s the LoRa bitrate (BW/SF/CR) and TX power for your 250uA estimation?
Also, I’m wondering if you have implemented any kind of power buffer or step-up when using a LiSOCl2 cell? Asking that because those cells have a tendency to drop voltage (and reduce their capacity) during a big current spike, for example, during a slow bitrate LoRa transmissions which might take 1-2 seconds? (reduced voltage normally translates in lower RF TX power output)
As mentioned on the Tindie product page, my standard power test is with a 3.7 V, 105 mAH LiPo battery. The LoRaWAN Tx rate is every 10 minutes with GNSS fix @ EPHE < 10 criterion every two hours. This includes sensor reads and all data logged to the SPI flash every minute, but this is a tiny fraction of the power usage. GNSS is highest usage with LoRaWAN a distant second.
Typical LoRaWAN settings are:
LoRaWAN.begin(US915);
LoRaWAN.setADR(false);
LoRaWAN.setDataRate(1);
LoRaWAN.setTxPower(10);
LoRaWAN.setSubBand(1); // 1 for MTCAP, 2 for TT gateways
I am not entirely sure I remember off the top of my head since I use these settings as a black box most of the time but I believe the data rate and TxPower are fixed to their lowest settings, which results in SF9 and BW125kHz. All of the power usage tests are done with the asset trackers within 10 meters of the gateway so they do not include the extra Tx power that would be necessary for longer ranges. But as I say, GNSS dominates the power usage in these tests. With similar test set up and LoRaWAN configuration the LoRaSensorTile (no GNSS) uses ~40 uA.
I have not used a LiSOCl2 battery in my power tests yet. And it is true that at least on start up the Asset Tracker power usage can spike well above 100 mA; but it is typically well below this after start up since GNSS and LoRaWAN are rarely ever aligned. So during the normal device run peak currents are typically ~35 mA. But many LiSOCL2 batteries claim 100 mA continuous and 200 mA peak current discharge rates. So while I haven’t tried yet (maybe next on my list of things to do) I relied on the quoted peak current and the quoted 2400 mAH capacity for the longevity estimates.
I do have a very small booster that could serve well with the LiSOCL2 batteries if needed so I doubt it would be a problem to use these batteries even if the power might sag. The booster is a passthrough for any input voltage above 3.6 V and a booster for any input voltage below 3.6 V down to ~1 V. I don’t offer them for sale anymore but I have access to a production line for them and I can always assemble some myself, of course. The very low self-discharge rate compared to standard LiPo batteries makes the LiSOCL2 batteries attractive for battery-powered remote end nodes.
There is at least one 3V3/GND port on the board edge which can be used to connect a power source directly. I would limit this to 3 - 3.3 V sources in general. I can’t remember off the top of my head what the lowest maximum input voltage is for components on these boards. But you could use a 3 - 3.3 V coin cell for example or some other 3.3 V source if you wanted. In this way you could bypass the main LDO.
Peak power is probably a good concern. I might want to add some power capping logic, especially on startup, so that you can have only turned on either SX1276, or the GNSS at one point of time.
Just a brief update. I used one of these to power a longCricket Asset Tracker with success.
I first powered the longCricket and loaded the asset tracking program via USB. In this case, the LoRaWAN was set to a one minute duty cycle and the GNSS was set to obtain a fix every five minutes. Once I verified everything was working I disconnected the USB.
Then I connected the 1/2 AA LiSOCl2 battery. There is no USB so I had to rely on the CayennaLPP to make sure everything was working.
Battery reporting 3.68 V or so, GNSS is accurate and updating every five minutes as expected, LoRaWAN coming at expected intervals. So whatever the startup current or continuing current drain might be these LiSOCL2 batteries seem to be able to manage without the need for a boost converter.
Here is the battery plot from CayenneLPP. Maybe the initial slight droop is due to the start up peak current draw, and despite the coarse resulution here (every minute) the droop doesn’t seem too bad.
IMHO it is ridiculous to use 1.8 v to 3.3 V logic level conversion for this sensor. 3V3 works just fine, and is what I am using for both longCricket and Gnat. The power usage difference between 1.8 V and 3V3 for the BMA400 is measured in tens of nA.
Maybe a silly question: I’m not a seasoned programmer. I don’t quite understand what’s happening here, how should I see period and delayed? Can you explain what is happening here?
The idea is that there is a time delay before the first call back and a time interval between subsequent callbacks. So in this example (not written in stone) there is a 100 second delay after the start of the sketch before either callback is called. For the long duty cycle, every two hours GNSS is re-enabled, a fix is obtained, and then the GNSS module is put back to sleep. For the short duty cycle, the GNSS fix is obtained more frequently to track the device’s motion. That is the purpose of these two.
In testing, it is convenient to dispense with the short duty cycle callback to get a repeatable measure of power usage from test to test when I know the device is stationary, which is why I sometimes set them both to the same two hour fix interval.
Hi,
I understand the difference in time interval when it comes to movement and no movement, respectively two hour timer or one minute timer. But I don’t understand what the other number does. Why is there another delay?
So time has origin at 0 seconds and with timerMillis one can define an offset from this origin as well as an interval from the origin to an even and between subsequent events. Offset tingthe time origin is useful since the initial part of most programs is where one configures and calibrates sensors, etc. and it is convenient to delay radio Tx until this is done. It is also useful to be able to control relative actions. Like I might want to first read sensors and then ten seconds later send out LoRaWAN Tx but have both of these at the same ten minute interval. For this you need a time origin offset as well as a time interval.
Yes, I am very pleased with the longCricket. It has taken me some effort to “train” the fab to do what I want. They are now able to approach 100% yields with very little rework required.
Let me know if you have any further questions about how to use these devices…and, tell your friends!;>
