I have a Things Network Indoor Gateway. I’ve configured a node using the E5 module with the stock AT firmware and it’s all registered with The Things Network correctly. I have a couple of concerns that I’m hoping someone can help me better understand.
My first concern is that I get “Join Failed” often. Even if I put it into AUTO JOIN mode 0 by doing “AT+JOIN=1” I get output like this:
+JOIN: Start
+JOIN: NORMAL
+JOIN: Join failed
+JOIN: Done
+JOIN: Start
+JOIN: NORMAL
+JOIN: Join failed
+JOIN: Done
+JOIN: No band in 27758ms
+JOIN: Start
+JOIN: NORMAL
+JOIN: Join failed
+JOIN: Done
+JOIN: Start
+JOIN: NORMAL
+JOIN: Join failed
+JOIN: Done
+JOIN: No band in 27002ms
+JOIN: Start
+JOIN: NORMAL
+JOIN: Join failed
+JOIN: Done
+JOIN: Start
+JOIN: NORMAL
+JOIN: Network joined
+JOIN: NetID 000013 DevAddr XX:XX:XX:XX
+JOIN: Done
My second concern is that if I successfully join, then power the unit off, then attempt to do a CMSGHEX command, the module responds with “+CMSGHEX: Please join network first”. I was under the impression that a successful JOIN should have a lasting effect so that you don’t have to re-join before every send, but it seems to me like loss of power to the E5 module causes that to not be true. Is that right? That’s kind of a major problem for my application because for power conservation my system disconnects power between transmissions. I assume this is because the E5 module lacks non-volatile storage for session keys or something like that. Is there a way for me to save these in my own non-volatile storage and restore them into the E5 module after powering up to overcome this problem?
In a brief follow up to this, I’ve taken some timing measurements and I’ve seen it take ~55 seconds to JOIN and about ~20 seconds (after that) to complete an CMSGHEX command. Is that normal?
I’ve also seen it take as little as ~16 seconds to JOIN and ~7 seconds to complete MSGHEX (unconfirmed send). I think if I can simply overcome the need to re-join after every power cycle the performance will be satisfactory for my application.
@Baozhu when can I expect to get a reply on this forum? I’m in development to use the E5 module on a product and a reply to this issue is currently blocking my progress. Is there a more direct line of engineering support available?
Hi,
about your second concern, I have the same findings.
After successfully joined and package send, LoRa-E5 is disconnected from power.
Couple moments later, after power up, I need to manually rejoin to send new package.
If there will be no need to rejoin it will be great.
Yes, it completely defeats the low power nature of LoRaWAN for my use case, and I would imagine a huge number of others too. I would categorically consider it a bug in the implementation of the AT slave firmware, and I hope someone from Seeed engineering support team will reply someday with a response, since it’s been almost two weeks since my original post at this point.
Since I’m trying to use these on a product, it would be very helpful to know a target date for when the firmware fix will become available, and it would further be useful to know if the fix will be made available as a binary (e.g. a hex file) that I can load onto existing units that I already have with an ST-LINK over JTAG.
Because the requirements have been submitted to the R&D department, they need to schedule to complete, there is no way to give you a very certain time, it is expected to be completed within a month.
What about my question about whether it will be possible to update the AT Slave firmware on existing units with Seeed providing a hex file to use with an ST-LINK and JTAG connection?
Please is there a way I can be notified / emailed when this new binary becomes available, I would be happy to help try it out and confirm it before pubic release if that’s helpful.
?