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.netOn 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.