And… not fixed in 4.4.0.58 
And… not fixed in 4.4.0.64
Do you have a XA2 or a XA2 Dual SIM?
I checked again (now both 10 and 10III) and 2nd command seems to work now.
But first one (GetCells) returns an empty array on 10III.
As this topic got some attention recently I decided to do some more test rounds to see if anything has changed recently.
At first it seems I got proper replies, only to find out it does not update when for example cell-id’s change. It gives the strong impression I am getting only cached results. After restarting ofono all I get is empty results once again.
Is this commit related?
It seems some changes were made for 4.2 that didn’t always update that data unless someone was subscribed to it.
1 Like
Looks like a change that could be related.
Is there any way I can verify this by way of a change in some settings to change the behavior, or even some experimental ofono package? Or do I indeed need to subscribe to some service/channel now and if so, how?
From the looks of that commit, subscribing to that dbus property might be enough to start it populating. If I start a map app, and I have the mlsdb active, that call works.
1 Like
I think calling GetCells cold should still return valid data, and is possibly a case that these changes have missed so I’ve filed a bug internally. You might be able to get something working from that commit in the meantime though. I think the mls geoclue plugin is using some QOfonoExtCellWatcher:
For a program running in the background that on-demand behavior shouldn’t a problem because the first org.nemomobile.ofono.CellInfo.GetCells call enables cell info tracking and then updates start coming. Or at least that’s how it’s supposed to work.
org.ofono.NetworkMonitor.GetServingCellInformation temporarily enables cell info update notifications and waits up to 10 sec for an update to arrive. From dbus-send (a short-lived client) that should actually produce non-empty result more often than org.nemomobile.ofono.CellInfo.GetCells, I’m surprised to hear the opposite. That also depends on whether the modem is currently registered or not.
In any case, the result of the initial query shouldn’t be assumed accurate. Keeping cell info notification enabled generates D-Bus traffic and extra wakeups from the modem, which was the reason for enabling those on demand.
3 Likes
Issuing org.nemomobile.ofono.CellInfo.GetCells seems to trigger a refresh of data, so GetServingCellInformation then shows up-to-date data it as far as I can tell.
I’ll see if this observation can help me restore the functionality of a program I had running before this broke down.
Thanks Abranson and Slava for stepping up to discuss this.
Still makes me wonder if this possible powersave change was worth abandoning accurate cell data info. I know this info is not used by an average user, but still.
I forgot to mention (I thought it was obvious, but just in case…) that our ofono tracks D-Bus clients which implicitly requested cell info updates with GetCells and as long as at least one such client stays alive, updates will keep coming.
Thank you. I’m now getting signals when cells get added or removed:
[D] cellsAdded:441 - cellsAdded result…: [/ril_0/cell_1467,/ril_0/cell_1468,/ril_0/cell_1469,/ril_0/cell_1470,/ril_0/cell_1471,/ril_0/cell_1472,/ril_0/cell_1473,/ril_0/cell_1474,/ril_0/cell_1475,/ril_0/cell_1476,/ril_0/cell_1477,/ril_0/cell_1478] 12
[D] cellsRemoved:445 - cellsRemoved result…: [/ril_0/cell_1466,/ril_0/cell_1469] 2
But how do I query data of the individual cell after extracting the paths from the signal as org.nemomobile.ofono.Cell.GetAll seems not to work any more?
Here’s a little test program demonstrating how this API is supposed to be used.
#include <QCoreApplication>
#include <QDebug>
#include <qofonoextcellwatcher.h>
class CellWatcher: public QObject
{
Q_OBJECT
public:
CellWatcher(QObject* aParent);
static void dumpCell(QOfonoExtCell* aCell);
void dumpCells();
public Q_SLOTS:
void onCellsChanged();
void onCellChanged(QString aName, int aValue);
private:
QOfonoExtCellWatcher* iWatcher;
QList<QSharedPointer<QOfonoExtCell> > iCells;
};
CellWatcher::CellWatcher(QObject* aParent) :
QObject(aParent),
iWatcher(new QOfonoExtCellWatcher(this))
{
connect(iWatcher, SIGNAL(cellsChanged()), SLOT(onCellsChanged()));
dumpCells();
}
void CellWatcher::onCellsChanged()
{
int i;
for (i=0; i<iCells.count(); i++) {
iCells.at(i)->disconnect(this);
}
iCells = iWatcher->cells();
for (i=0; i<iCells.count(); i++) {
connect(iCells.at(i).data(),
SIGNAL(propertyChanged(QString,int)),
SLOT(onCellChanged(QString,int)));
}
dumpCells();
}
void CellWatcher::onCellChanged(QString aName, int aValue)
{
QOfonoExtCell* cell = (QOfonoExtCell*)sender();
qDebug() << cell->path() << aName << "=>" << aValue;
}
void CellWatcher::dumpCells()
{
if (iCells.count() > 0) {
qDebug() << iCells.count() << "cell(s)";
for (int i=0; i<iCells.count(); i++) {
dumpCell(iCells.at(i).data());
}
} else {
qDebug() << "No cells";
}
}
void CellWatcher::dumpCell(QOfonoExtCell* aCell)
{
switch (aCell->type()) {
case QOfonoExtCell::GSM:
qDebug() << aCell->path() << "gsm" << aCell->registered() <<
"mcc:" << aCell->mcc() << "mnc:" << aCell->mnc() <<
"lac:" << aCell->lac() << "cid:" << aCell->cid() <<
"signalStrength:" << aCell->signalStrength() <<
"bitErrorRate:" << aCell->bitErrorRate();
break;
case QOfonoExtCell::WCDMA:
qDebug() << aCell->path() << "wcdma" << aCell->registered() <<
"mcc:" << aCell->mcc() << "mnc:" << aCell->mnc() <<
"lac:" << aCell->lac() << "cid:" << aCell->cid() <<
"psc:" << aCell->psc() <<
"signalStrength:" << aCell->signalStrength() <<
"bitErrorRate:" << aCell->bitErrorRate();
break;
case QOfonoExtCell::LTE:
qDebug() << aCell->path() << "lte" << aCell->registered() <<
"mcc:" << aCell->mcc() << "mnc:" << aCell->mnc() <<
"ci:" << aCell->ci() << "pci:" << aCell->pci() <<
"tac:" << aCell->tac() <<
"signalStrength:" << aCell->signalStrength() <<
"rsrp:" << aCell->rsrp() << "rsrq:" << aCell->rsrq() <<
"rssnr:" << aCell->rssnr() << "cqi:" << aCell->cqi() <<
"timingAdvance:" << aCell->timingAdvance();
break;
default:
qDebug() << aCell->path() << "unknown" << aCell->registered();
break;
}
}
int main(int argc, char* argv[])
{
QCoreApplication app(argc, argv);
new CellWatcher(&app);
return app.exec();
}
#include "test.moc"
1 Like
Ah, so if I understand this correctly this means it’s not possible to get cell info from dbus?
Of course it’s possible, this libqofonoext thing is just a wrapper around D-Bus. If nothing else, it’s an example how to use the D-Bus API. I think the library API nicely demonstrates the basic workflow: get the initial list of cells => watch for arrival/removal of cells => request cell properties => watch property changes for each individual cell.
That was, kind of, the point of my initial question. I’m getting the cell paths for the individual cells but which dbus service/interface do I query the cell properties from?
I rather keep this bug report on topic, it starts to turn in a only very distant related help request.
It seems you were aware of the initial issue yourself, an earlier confirmation post here might have helped to get attention for this issue sooner.
Here it is:
<interface name="org.nemomobile.ofono.Cell">
<method name="GetAll">
<arg name="version" type="i" direction="out"/>
<arg name="type" type="s" direction="out"/>
<arg name="registered" type="b" direction="out"/>
<arg name="properties" type="a{sv}" direction="out"/>
</method>
<method name="GetInterfaceVersion">
<arg name="version" type="i" direction="out"/>
</method>
<method name="GetType">
<arg name="type" type="s" direction="out"/>
</method>
<method name="GetRegistered">
<arg name="registered" type="b" direction="out"/>
</method>
<method name="GetProperties">
<arg name="properties" type="a{sv}" direction="out"/>
</method>
<signal name="RegisteredChanged">
<arg name="registered" type="b"/>
</signal>
<signal name="PropertyChanged">
<arg name="name" type="s"/>
<arg name="value" type="v"/>
</signal>
<signal name="Removed"/>
</interface>
It can queried directly from ofono at run time:
dbus-send --service --print-reply --type=method_call --dest=org.ofono /ril_x/cell_yyy org.freedesktop.DBus.Introspectable.Introspect
(you’d need to substitute /ril_x/cell_yyy with a real cell path). Although when I forget what it is, I usually open the source code.
To query cell properties from the command line you can do something like this:
dbus-send --system --print-reply --type=method_call --dest=org.ofono /ril_x/cell_yyy org.nemomobile.ofono.Cell.GetAll
In order for such dbus-send call to work reliably, a long-running client (like the test program I posted above) must be keeping updates on.
3 Likes
I’ll draw this to a conclusion before this thread continues to discuss issues not directly related to my bugreport.
The missing/outdated cellinfo is due to a change in the code in SFOS 4.2, which make this info not update itself anymore. It has not become clear to me if this a unintended side effect and/or if this behavour will changed again.
The workaround is to call org.nemomobile.ofono.CellInfo.GetCells first, which forces this info to be updated.