For reference, the commands I use to reset the modem are:
gpio -g mode 26 out
gpio -g mode 19 out
gpio -g write 26 1
gpio -g write 19 1
sleep 2
gpio -g write 26 0
gpio -g write 19 0
Derived from https://github.com/sixfab/Sixfab_PPP_Installer/blob/master/ppp_installer/reconnect_basehat
After it gets connected after half a minute it disconnects and is never being able to reconnect without reset:
ModemManager[4418]: <info> [1581089085.188237] Simple connect state (8/8): All done
ModemManager[4418]: <debug> [1581089085.189675] (ttyAMA0) device open count is 2 (close)
ModemManager[4418]: <debug> [1581089089.914441] Couldn't load network timezone: No AT port available to run command
ModemManager[4418]: <warn> [1581089089.915021] Couldn't load network timezone from the current network
ModemManager[4418]: <debug> [1581089105.929633] User request to disconnect modem (all bearers)
ModemManager[4418]: <debug> [1581089105.930327] Disconnecting bearer '/org/freedesktop/ModemManager1/Bearer/0'
ModemManager[4418]: <info> [1581089105.930815] Modem /org/freedesktop/ModemManager1/Modem/0: state changed (connected -> disconnecting)
ModemManager[4418]: <debug> [1581089105.932760] Reopening data port (ttyAMA0)...
ModemManager[4418]: <debug> [1581089105.932908] (ttyAMA0) reopening port (2)
ModemManager[4418]: <debug> [1581089105.933412] (ttyAMA0) device open count is 1 (close)
ModemManager[4418]: <debug> [1581089105.933727] (ttyAMA0) device open count is 0 (close)
ModemManager[4418]: <debug> [1581089105.934231] (ttyAMA0) closing serial port...
ModemManager[4418]: <debug> [1581089105.934546] (ttyAMA0): port now disconnected
ModemManager[4418]: <debug> [1581089105.934940] (ttyAMA0) serial port closed
ModemManager[4418]: <debug> [1581089105.940058] User request to disconnect modem (all bearers)
ModemManager[4418]: <debug> [1581089105.945414] User request to connect modem
And sometimes it does not even reach that stage, but gets borked in the middle.
That’s all from me at this stage. Please ping me when better power is available.
I changed out the 2A (no brand) power adapter for a 2.5A branded power adapter!
It the heaviest I have.
If this doesnt work I need to order a 3A model.
(ps I never work with sketchy usb cables, only with power supplies with micro usb cable attached)
Will recheck now.
There are still voltage drops when the modem is reset/commands are running. This is probably due to the fact that the supply is rated at 5.0V. The official power supplies are rated at 5.1V, e.g for RPi 4 these are 5.1 and 3A.
I have seen many times voltage issues reported by the RPi firmware on users’ devices, but they rarely are the cause for issues I have been looking at, so so let’s see what @aleksander0m may share above the errors above.
Once the modem gets in a borked state, it needs to be reset. I left a small reset.sh script in the main container that contains the gpio commands above.
But @majorz the weird thing about your theory is, that the device does not seem to have a problem setting up a PPP connection using this tutorial (linked from the HAT product page):
If you follow that instruction using the following settings:
Then it starts a PPP connection without any trouble. How can we explain that if it is a power issue?
Sadly that connection is managed from the container instead of the hostOS, so it is not a structural solution in my opinion.
Yes, this is what I meant - at this point it looks more like ModemManager/NetworkManager related.
The fact that MM sees a “user request to disconnect modem” log is because the failure at this point is at NetworkManager level. The process should be something like this:
If you could get NM logs during one such connection attempt, we may see why it’s failing. It could be anything, like pppd not even installed or just a wrongly configured APN.
Thanks for the useful insights! I will grab the logs now and post them here.
NetworkManager launches pppd successfully, but afterwards the pppd plugin does not respond back through D-Bus for some unknown yet reason: pppd timed out or didn't initialize our dbus module. I found one similar report under our OS and another one for Raspbian.
There are no journal logs from pppd to indicate anything, which should not be the case.
A discrepancy I saw is that pppd is version 2.4.7, but the plugin path is /usr/lib/pppd/2.4.5/nm-pppd-plugin.so. Maybe that is a red herring, but it is worth exploring further. I am going to try running pppd manually on top of ModemManager to see if I will have some better luck.
Hopefully it is some easy-to-fix build configuration issue.
I will continue looking into this on Monday. Have a nice weekend guys!
Hey guys,
I went by the office today to do some more testing. I have some new insights:
I noticed that the Status-LED on the 4g HAT actually indicates that there is a connection, even though MM is not controlling it
I also noticed that my SIM provider also registers an active data connection on that SIM, as soon as I power the RasPi.
Additionally, I tried simply powering the HAT without it being connected to a raspi, and again it seems the HAT automatically creates a data connection (status-LED & simcard provider indicate there is indeed a connection).
Could it be that the HAT hardware itself is creating the connection?
@FransvanHoogstraten ModemManager completes its job in setting up the connection successfully and then delegates it to pppd through NetworkManager. Since the modem is connected to the cellular network, there will be indications for that.
Can you please provision a different SD card with Raspbian Lite, install NetworkManager and ModemManager on it and check whether it will be working? Raspbian comes with older package versions, but since I suspect at this stage that this is a configuration issue with pppd on our side, I do not expect that we will see the same problem.
You will need to add the same udev rule and same NetworkManager profile.
As a couple of side notes:
ssh empty file (touch ssh) at the top of the boot partition, so that you may ssh to the device easily. The default username/password is pi/raspberry. It is a sudoer account.bash <(curl -L https://github.com/balena-io/wifi-connect/raw/master/scripts/raspbian-install.sh).Please let me know if you have any questions. I started looking at what possibly could be wrong with our pppd setup.
Thanks,
Zahari
OK @majorz , I will. I just need to find the time to do this somewhere the coming days.
Just to double check:
I have flashed a new device with hostOS 2.36 (because I saw in the changelog that for the last few releases they’ve been tweaking modemmanager, so I thought lets move to an older stable release).
I now get these debug logs from ModemManager ==> LINK
Could you take a look at these as well? Does this behaviour match your theory?
You can definitely see some serial communication happening.
This device with earlier OS version does not go very far in the connection sequence compared to the other device. There is some serial communication happening with the other device also, but it breaks when pppd launches. With this one it does not even reach the stage to launch pppd.
I received the Sixfab HAT and debug the issue locally. I will keep you updated on how that goes.
Thanks,
Zahari
For reference this is the opened GitHub issue: https://github.com/balena-os/meta-balena/issues/1846. I will post an update here as well once it is resolved.
For posterity purposes I’d like to inform you that the Gh issue NetworkManager times out on pppd when setting up UART modems · Issue #1846 · balena-os/meta-balena · GitHub is now resolved.