I am trying to switch to Imp from Particle. I’ve had it with their cellular issues and overall lack of stability.
I purchased two imp006s to start out, to see how hard it will be to replace my highly refined Particle Boron controller code. It’s a big task to redo this and I hate Squirrel compared to Arduino/C.
I need to not have to sign up for some bothersome, onerous, and annoying account on Azure. I just want out-of-the-box functional mqtt like Particle offers me.
Is this possible?
How can I proceed? I take it we can’t use MQTT on the agent either?
Thank you for your help as I make a decision whether to use imp + Particle or to totally phase out and trash all my Particle. For me, reliability and stability (i.e., not necessarily 100% uptime, but not ever entering states of permanent disconnectivity requiring manual servicing) is my #1 priority. I am not looking to do anything fancy. I only upload small binary packets (<200 bytes) every minute from UART to the internet using MQTT. That’s all I need. I use a separate Teensy microcontroller for the actual sensor interfacing and I just need an LTE board that will give me stable, usable cellular (it would be a huge plus if we could get input-capture-register-using FreqMeasureMulti-equivalent library for imp006 but that’s a separate topic).
MQTT is only available on the agent (ditto for HTTP). Every device has its own agent, and that’s where integration with cloud services happens - all the heavy stuff like TLS certificate chain verification is happening on a server then which is much better for you battery life.
If you’re trying to do MQTT on the device, that’ll be why you’re seeing errors.
You can connect to any compatible broker - we have a great Azure integration including the device provisioning service, but that’s just an open source wrapper around an MQTT connection and some restful APIs.
Thanks @hugo - I subsequently got the agent to work with regular HTTP because I was so excited to make my system work with imp. I am really liking your product. If you remember, you connected with me on competitor’s forum PM and I wish I had taken up your advice earlier.
I was impressed today when I did my reconnection test on the imp006. I left it up overnight with no antenna. Then I connected the antenna this morning, and within the 9 minute sleep cycle it perfectly connected. Compare that to your competitor which I sadly have been using at all my remote deployments at great expense to my mental health. They disconnect and never reconnect. Your units are twice the cost, but if the stability holds, that is well, well worth it.
Kinda off-topic, but can you provide any anecdotes/reassurance of people using cellular imp006’s in the field for long duration remote monitoring with high stability? Do we need to have an external watchdog circuit for the imp006? I am evaluating the imp006 and I might just entirely switch over to imp. Can you point me in the right direction as it regards using imp006 to make a stable, reliable, always-eventually-reconnecting-when-there-is-signal-and-power remote IoT monitoring device? I am looking for a product that will force me to go make field visits only when there is a legitimate reason, i.e. the power supply failed, i.e., not that there’s a software/firmware issue in reconnecting to the cell tower which a human power cycle instantly fixes (cough Particle). How does the imp006 Quectel modem compare to the Boron SARA ublox modem in this regard? Thank you.
BTW - I believe your device/agent model is less bandwidth intensive than having device-side MQTT to begin with. I would love to know how much overhead agent.send has. It’s got to be less.
Well, in production our units are likely less than half the price - because you’re buying a radio and imp006 MCU (which will be stocked by distributors in the near future) instead of a module someone has built and marked up… we’re a software company, not a hardware company.
The 9 minute sleep/retry is just default behavior too - if you wanted a faster reconnect, I’d recommend using the connection manager library, but do change the connect timeout to 600s for cellular devices - you specify this during initialization.
imp006 is pretty new, but most customers using cellular are using them in remote/inaccessible places hence connection reliability is paramount. Note that we are still on pre-release software - 42.x will be the first production release for the extended imp family including 006 - but the remaining known issues are generally small.
To be honest, we’ve never found a modem that is particularly bug-free. They all have their issues, uBlox included, but Quectel’s BG96 is a very widely used high volume product (possibly the biggest selling module of its type globally). That gives them more field experience and hopefully better stability.
agent.send is over TCP/TLS, we account for 150 bytes overhead on top of the data you’re transmitting, including the TCP ACK. Unlike particle, there’s no arbitrary data size limitations on transmissions but obviously it still pays to ensure data is well packed before sending - deeply nested tables will be sending a lot of data related to the structure vs the data you want to send. Also, last time I looked our data was a fraction of their data cost, making data usage less of an issue - we specifically priced it to get people shipping good applications vs worrying about every byte.