Dectmon only recording data partially?

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/linux-dect@lists.osmocom.org/.

Patrick McHardy kaber at trash.net
Mon Nov 15 14:42:51 UTC 2010


On 15.11.2010 15:25, Erik Tews wrote:
> Am Montag, den 15.11.2010, 15:14 +0100 schrieb Patrick McHardy:
>> Indeed, the multi-frame resync timer has timed out (mfn:9, max is 8).
>> It seems it didn't receive a valid tail message over the entire
>> previous period, judging by the log. I'd guess that the transceiver
>> has drifted off too much. You should be able to see that by watching
>> the output of dect-transceiver-list for the slot in question.
>>
>> Does locking to that PF work if you don't use monitor mode? 
> 
> I will check that.
> 
> One strange thing, while scanning, I get a lot of messages with:
> 
> identities information: e: 0 class: 0 emc: ....
> 
> So my kernel finds a lot of PPs around it, but the Fritzbox is in the
> same room, only a few meters away, and it takes a minute or more until
> the Fritzbox pops up here.
> 
> As I understand the code at the moment, during the initial scan for the
> FP, the timing of the transmitter doesn't really matter. So we might
> assume that it is not a timing-problem which is responseable for this
> effect?

Correct, timing shouldn't matter, at least for receiving the first
identity information frame from that FP. The scan isn't really optimal
currently though, as soon as it has received all information from
one FP, it switches to the next carrier. With some bad luck, this
might cause it to miss an FP indefinitely. What it should really
do is stay on the same carrier and only switch if the next FP it
discovery is already known.




More information about the linux-dect mailing list