Cannot get past LTE
from network import LTE
lte = LTE() #fails with "the requested operation failed"
How do i fix this..reseting fipy does nothing.
tuftec last edited by
@John-Baird Hi John, interesting comments. Thanks for your input.
I gather you are using the deepsleep functionality of the unit.
I find that the deepsleep call hangs periodically and needs to be helped along with a kick from the WDT every so often.
The actual LTE communications part seems to work quite well once you work out how to drive it.
I do find every so often that I get strange failures that are difficult to explain.
I would be keen to understand the steps you have taken to achieve an acceptable degree of reliability, as I am sure are others.
Do you use in sort of real time control within your application. I have a number of functions that need to happen on a periodic basis (from minutes to hours to days to monthly). I am just trying to get my mind around how I might be able to use the RTC for this. Working out how to initialise it/synchronise it is another challenge.
I have a need to toggle an output pin every 2 seconds when my device is asleep. I sleep for 2 minutes at a time, to conserve power. I ended up having to resort to an external circuit to toggle the output as I could not see an easy way to do this with the FiPy. I could have probably used the ULP, but this is a bit beyond me at present.
John Baird last edited by
@misterlisty Yes, I have it running with Telstra. Typically my units run for around a month on batteries and encounter no problems. To achieve that took time and lots of error handling. It's all rather delicate. For example, on the weekend I introduced a new thread for handling the raw data from the GPS and suddenly LTE attachment stopped working. No errors from the code, it just wouldn't attach. Take out the launch of the GPS thread and attach works again.
Unlike @Steve-Williams I drive much of the process myself through AT commands as I don't trust that the Pycom magic won't break unexpectedly. Someday I'll convert over, but they will have to earn more of my trust first. With so little documentation it's been very frustrating having to do so many "black box" experiments to figure out what's inside.
robert-hh last edited by
@misterlisty Yes, since a few weeks. With the new/upgraded FiPy devices it works. I can attach, connect and exchange data. But it took since the FiPy kickstarter campaign's first sales. To be honest, most of the waiting time was caused by the LTE provider not offering the service and not selling SIM cards to ordinary people. They just sell it to companies. What a mess! After I got cards, I could tell that FiPy does not support that LTE band, .....
It's difficult for a small vendor like Pycom to deal with all variations of the world. And obviously even a "standard" allows a lot of variety. Intentionally, if you look at how a standard evolves.
@robert-hh thank you Have you been able to use LTE successfully?
robert-hh last edited by
a) send_at_cmd_pretty() is just a wrapper for lte.send_at_cmd() written by someone to have a more clean output. No magic.
b) Extended AT (Sequans specific? )commands start with AT!=. For a list of Sequans AT commands, see: https://docs.pycom.io/.gitbook/assets/Monarch-LR5110-ATCmdRefMan-rev6_noConfidential.pdf
cAN ANY EXPLAIN WHERE THESE TYPES OF COMMANDS ARE COMING FROM?
send_at_cmd_pretty('AT+CFUN=0') #what is send_at_cmd_pretty is this documented or some wrapper?
send_at_cmd_pretty('AT!="clearscanconfig"') # What is the purpose of AT!=?
@Steve-Williams Appreciate your response and assistance
@misterlisty I will try to cut the relevant portions of code out so I can send them to you. My full code is a bit wordy (I'm old school and my Pycom experience has been that the code steps need to be seperate, not concatenated and in the case of LTE in particular, provide with pauses to allow tasks to be actioned. The use of threads and timers to separate functions from one another helps this situation). It will take a few days, as I am pretty busy with the paying product.. :-)
@tuftec "I am also seeing variation between different versions of FiPy modules. It appears that my earlier unit (which does not support Vodafone) draws more current than the later unit under identical conditions."
Yes, hardware and firmware changes are fine and to be expected as improvements are made, but the documentation doesn't seem to keep up.
A while ago, in response to some questions about the problems I was encountering, Pycom advised that I should not have been using AT!= commands anymore, but as far as I am aware there is no updated documentation from Sequans or Pycom in support, so it is very frustrating.
I have suspected the power design for a while, especially the Expansion Board 3 which remains in 'secret' status... For deep sleep, I also encountered problems but with a decent battery power supply that became a non issue for me, and I made sure I only connected any of the comm's services when they were requires and disabled them when finished (deinit commands).
It's frustrating that the Pycom devices aren't as reliable as needed, especially for remote installations. It means a lot more code to provide workarounds and error traps to maintain operation. A great product if the development was completed - at this stage though I can't consider them as reliable mature product.. more work is required to avoid a huge overhead cost in product development time.
tuftec last edited by
I have been experimenting with using the FipY product for NB-IoT, LoRaWAN and Sigfox here in Australia.
I have been able to have some success with the Vodafone network.
But like Steve, my biggest concern is with regard to stability.
I see some really strange errors poping up at times.
The biggest issue I currently have is to do with deepsleep calls, which appear to fail every so often.
I have a work around in place using the WDT feature, but this is not ideal.
I am also seeing variation between different versions of FiPy modules. It appears that my earlier unit (which does not support Vodafone) draws more current than the later unit under identical conditions.
I like the features and multi-technology convenience of the FiPy, but the stability issues are testing me.
If you search in the Bugs area of this forum for deepsleep issues, you will come across my posts. There is some code there that might help with setting up the LTE bits.
@Steve-Williams thank you for your reply..curious to know what product you are using now. I do like the pycom devices but very disappointing that the lte not working as should. Maybe more effort on existing product development instead of new designs would be better. I have experience with GHI Electronics products but not as fancy as pycom devices. But I love c# which is my proficiency.
I'm in Australia also :)
@misterlisty Is there an Expansion Board or the like in you configuration?
@misterlisty It took a lot of effort to get my code reasonably stable but yes, LTE to can be very inconsistent. I have concerns about the GPY/FiPY code stability - and experimented a lot with different firmware combinations - GPY/FiPY and the embedded SEQUANS device. But as previously stated, I have moved away from the Pycom solution for a serious product under development simply because it is so flaky - in my experience the hardware seems to throw odd errors, for no apparent reason (for example it connected consistently for months, then suddenly started with errors that were hard to diagnose with the current documentation. The same thing happened with WLAN, which makes me think there is something not quite right - possibly an internal power supply problem.
I instantiate the LTE instance with lte = LTE('telstra', 'cid=1','band=28') and avoid as many AT commands as possible., as that has proven reasonably stable. You might also want to look at the Core Electronics tutorial for the GPY at https://core-electronics.com.au/tutorials/pycom-gpy-getting-started.html I'd also recommend the use of an external LTE antenna, with a bit more gain and the ability to locate it for better reception.
My code resets the modem and attach and connect every time it is called. The object is de-initialised after use - This seems to help, I suspect the modem doesn't settle properly after use.
I use a configuration script to store many parameters for the complete project code including the LTE and WLAN setups- calling them as required. This allows config to be updated by uploading a new config file as necessary. I have a lot of error detection in the code to manage those instances. Something else to look at is adding sleep pauses in your code, to give the modem time to settle after actioning a command. As it stands now (after a few weeks of not running - I have powered the GPY up again and it has been running error free for over 60 hours! However, my code is not easily cut out to give you an abridged version just for the GPY/FiPY.. but I can try as time allows me.. I am busy with saturation testing of the new product design unfortunately.
Maybe PM me if you need further assistance - but have a go, be patient and expect to experiment with timing, sequence and error trapping.. :-)
@jcaron Using the latest firmware of 3 days ago and using fipy.
jcaron last edited by
@misterlisty You should probably specify which version of the FiPy and modem firmware you are using.
Has anyone got LTE working with Telstra...seems very inconsistent...
shaunix last edited by
Try unplugging the power to do a hard reset (Not just press the reset button). I also recommend upgrading your modem to the latest firmware.
@misterlisty Depending which firmware is in place, you may need to instantiate the lte object by including the carrier etc..
try lte = LTE('telstra', 'cid=1','band=28')
for old firmware you might need to do this using AT commands. Pycom documentation is a bit light on for LTE (and other commands).. :-)
kjm last edited by kjm
You shouldn't have to I know but have you tried putting import network after import OS? I had an issue on a GPY where it wouldn't let me import from machine till I had imported machine first