@jirkakrepl said in New Pybytes firmware 1.18.1.r9 (Experimental LTE support):
If your LTE configuration is correct, your device with a Simcard should connect to Pybytes using LTE.
Then Terminal and Flash OTA update should work too.
Awesome, I'll try it out soon, thanks! LTE OTA was only thing holding us back from a production release.
Discussion for Feature Request and Future Additions to Pybytes
15
Topics
43
Posts
@robert-hh
yes, new chips are really interesting. Reading draft version of docs are promising.
As they send some testing parts already i suppose full delivery and final version of docs will be really soon.
I am really interested if ADC will be better in new chips ;-)
An update:
Thank you for the offline support. To give an update for the community to benefit from, the reason for the failure was due to a special character in the python file not covered by the ASCII format. The advice was to use only ASCII format in all the text/python files.
I have the same problem with Lopy4 and Wipy3 devices. Connecting manually to Pybytes is successful and I can see ping messages received by Pybytes in the browser, e.g. 'Last connection 2 seconds ago', but I cannot deploy a new release, upload from Github or list project hierarchy in pymakr online. Pybytes reports device as 'offline' even when pings are clearly being received. I have tried deleting and adding devices to Pybytes again, creating new projects, erasing device memory and re-flashing firmware (1.20.2.R4). I have also tried with brand-new Lopy4.
connecting to Pybytes...
WMAC: 3C71...
Firmware: 1.20.2.r4
Pybytes: 1.6.1
Initialized watchdog for WiFi and LTE connection with timeout 1260000 ms
WARNING! Using external WiFi antenna.
WiFi connection established
Connected to MQTT mqtt.pybytes.pycom.io
Hi @Oliver-Mayer,
Thank you for your feedback.
Pybytes team will take a look, and see why the release feature is not working for you.
I will get back to answer your questions.
Best Regards,
Ahmad EL Masri
I am sorry, forgot to post the solution.
I even had a quick skype call with one of the pycom developers.
Yes the solition was the same for me also. I renamed the file mqtt.py to something else like mqttclient.py, and it solved the issue. Somewhere deep there is a mqtt.py file in the pybytes firmware. That caused the issue.
You can look at this page: https://docs.pycom.io/pybytes/api/ to start pybytes manually. Set pycom.pybytes_on_boot(False). You can first setup the connection and for example check different SSID's, and when connected, call the code in the top codeblock to actually start Pybytes
@BetterAuto said in Pybytes with custom firmware?:
or am I required to use the pycom.ota_start() method?
Concerning the pycom.ota_start it is not required to be used.
If you want to implement this yourself please take a look at the below reference.
Reference: https://github.com/pycom/pycom-libraries/tree/master/examples/OTA
Ah, here is the reason. "WiPy2, SiPy, and LoPy1 and are not supported anymore since they only have 4MB flash." That was unexpected because the latest non-beta firmware works fine, but I knew this was coming some day.
Also, "No OTA support from Pybytes yet"
I tried with the updater and it says, "Your hardware is not supported by this firmware package"
https://forum.pycom.io/topic/7016/new-beta-release-v1-20-3-b3
Hi,
Thanks for the suggestions / testing. I'll add it to the bugs list. I understand the feature is not quite as robust as you'd like.
The Pybytes.conf file is unique to each device (it contains the unique id etc.), though Im not sure how that ties into the whole release process and if you have to include it.
@Gijs Hi. The output of dnsserver after pybytes.start is ('172.31.16.100', '172.31.32.100'), while the output of AT+CGCONTRDP? is always ERROR. I tried to move the AT command in different parts of the code but the result was always ERROR. When the device fails I cannot retrieve any information, so I don't know what the dnsserver output is. I'm using your Vodafone SIM in Italy. Thank you
Because the app eui is not checked for validity locally, but rather with the Chirpstack server somewhere in the backend. All three parameters are used to resolve the packets coming in over LoRa to your project console in Chirpstack.
If you're planning on using the Pybytes / Pycom Chirpstack server, you should configure your device (node) through Pybytes to use a LoRa connection and all the keys will be handled automatically. A gateway setup should be very similar to setting up to TTN, except for the different server address / (possibly) gateway eui. If youre not using the Pycom Chirpstack server, all three parameters should be available somewhere as far as I know.
Let me know if that answers your question
