We’ve been using some Boron devices with the hopes of sending spark/device/diagnostics/update messages from our devices to our home servers. The actual location data from this query is very important, since it’s later used to query Unwiredlab’s various API’s. We’re pretty fresh with this technology and are therefore still learning how to most effectively utilize particle’s services.
In testing, we’ve noticed that our device properly sends the correct message to Particle and we are able to receive and utilize it via webhooks. However, our device’s CGI rarely seems to give us the proper values. Specifically, the Location Area Code (lac) frequently returns 0 as opposed to it’s actual value. We have it set to send us device vitals once a day, and the Particle Console typically shows a 0 for the lac in the device’s overall cgi. The value is consistently 0 and seems to return a valid 5-digit number in an unpredictable manner.
The Boron is designed to wake up, send it’s device vitals, then go to sleep once a day. These devices are designed to conserve as much portable battery life as possible. That remains among the highest priorities for our team.
Here are our questions:
- Is there a reason particle would give us an lac value for 0 at all? What could likely cause this value to fail to send? Currently, our success rate for proper lac’s passing is about 30%.
- How exactly are lac’s derived? Our research and knowledge of the topic is a bit limited, as we are quite new to cellular services like Particle. Could this be a hardware-related issue on our side?
- When we query UnwiredLabs with a 0 lac value, our responses are usually valid locations that are nowhere near our actual location. Is an lac of 0 truly a valid number, is it just interpreted as null, and are all valid lac’s nonzero?
Thank you so much for your responses! God Bless!