For me I have never had a problem with MMS after I got the settings right for Ting Wireless. Other people have had trouble finding the right settings but it seems that after you find them it all works.
Thanks for this. I have set it up on my Pinephone so I know how to setup MMS, just making sure everything worked!
When driving in a car, the modem has difficulty transitioning from one cell tower to the next, causing any streaming data to stop. So if you are streaming music while driving, frequently the music will stop and you have to reset the modem. This is a longstanding, frustrating deficiency, and I don’t know if a fix will ever come.
I’m remnded of the old Bell Telephone policy on modem reliability, no modem was guaranteed above 300bps!
I have the BM818-A1 modem on T-Mobile with up-to-date modem firmware and up-to-date Byzantium. The data drop-outs happen so frequently I don’t bother streaming while driving anymore. Too frustrating.
That’s because of a bug in the kernel that causes it to suspend the USB bus. This is not just isolated to you. You can fix it by running this on boot (every boot… though you could probably make it run on startup): echo 'on' | sudo tee /sys/bus/usb/devices/1-1.2/power/control
cron has a special time of @reboot for startup so yeah a cron job with that schedule should work.
I will try it for a week and report back.
My first modem was the Texas Instruments modem chipset, a speaker and a mic in yogurt cups with the telephone receiver placed into said cups. Dialed into the BBS and it worked. As a teenager I was so pumped it worked. Of course you could read way faster than 300 baud, but that was my first foray into going on the line…literally…lol.
Is the suspension a bug, or rather a badly implemented power-saving feature? The default setting for that USB power control is “auto”, which sounds as though the power should come on when needed. Evidently it doesn’t reliably do so, and your fix does put a stop to the modem suspensions.
Should the developers look at making the auto setting more reliable? It seems a good idea to shut off the power when it is not needed, but obviously it should also turn on again at the right time.
SMS was unreliable for me for a while, but now works great.
MMS still does not seem 100% reliable.
LTE is requires a workaround to work reliably. It will disconnect multiple times per day for me and I need to manually switch the modem off and on (via hardware kill switches) to get it to work again. But, after doing this whenever I have any internet issue I have no trouble using its internet all day all across the greater Los Angeles area, other than the very annoying periodic restarts needed.
Edit: Looks like @Aberts10 has a fix in this very thread!
Now I just need to figure out how to set up the cron job to run this upon reboot rather than needing to manually run echo 'on' > /sys/bus/usb/devices/1-1.2/power/control
as root…
cron
supports the special string @reboot
instead of the first five fields.
I was mistaken in posting about a test which seemed to be successful but now I find to be otherwise. This post is withdrawn in its entirety.
Right this way?
login as root and modify crontab to:
@reboot echo ‘on’ | /usr/bin/tee /sys/bus/usb/devices/1-1.2/power/control
The crontab entry does not work, not even it does work on shell:
purism@pureos:~$ echo ‘on’ | sudo /usr/bin/tee /sys/bus/usb/devices/1-1.2/power/control
‘on’
/usr/bin/tee: /sys/bus/usb/devices/1-1.2/power/control: Invalid argument
Any ideas?
On the shell I nailed it down: the '
chars have been due to cut and paste some UTF-8 chars.
and specifically should not turn off while any data modem is supposedly turned on, even if there is momentarily no modem activity.
For root the crontab entry does not get executed. Don’t know why.
Running any cron job for user root
gives in ´/var/log/syslog`:
Feb 18 16:47:01 pureos cron[488]: (*system*) RELOAD (/etc/crontab)
Feb 18 16:47:01 pureos CRON[5410]: Authentication failure
Feb 18 16:47:01 pureos cron[5410]: Authentication failure
which must have todo with root
somehow being locked on the L5.
@dos, any idea how to make this working?
In another thread, there are strongly expressed opinions in both directions on the question of root account expiry. (Opinions are based on security on one side versus user freedom on the other.) The expiry date can be changed with the chage command (not a typo).
Setting expiry to tomorrow’s date, I rebooted and the cron job worked, i.e. the USB power control was ‘on’ rather than ‘auto’ after reboot.
Aside from the security aspect of non-expiring root account, there is the question of battery consumption if USB power is on by default even when no internet connection is in use. On an L5 turned on but doing nothing except waiting for calls or texts to come in, and starting at a battery level of 85% in both cases, the battery level dropped in 30 minutes to 81% with ‘auto’ USB, whereas it went to 79% with ‘on’ USB.
[EDIT 16:50 EST 20240218: The other thing that bothers me about enabling the root account is that there are four root commands already in /etc/crontab. They seem to be something to do with testing the device before shipping (and presumably before the root account was disabled). Since the device is shipped with those commands apparently not to be run, it might seem that they should be commented out by anyone who re-enables the root account. However, I just don’t know enough to be sure that it is appropriate either to let them run or to comment them out.]