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

Erik Tews e_tews at cdc.informatik.tu-darmstadt.de
Mon Nov 15 15:25:24 UTC 2010


Am Montag, den 15.11.2010, 16:19 +0100 schrieb Patrick McHardy:
> On 15.11.2010 16:14, Erik Tews wrote:
> > Am Montag, den 15.11.2010, 15:44 +0100 schrieb Patrick McHardy:
> >> You could try to add to dect_mac_irc_tick, the
> >> DECT_TRANSCEIVER_UNLOCKED
> >> case, around the carrier increment:
> >>
> >> if (net_random() > 0x7fffffff) {
> >> ...
> >> }
> >>
> >> to have it stay on the same carrier half the time. 
> > 
> > OK, that seems to improve the scanning results:
> > 
> > diff --git a/net/dect/mac_csf.c b/net/dect/mac_csf.c
> > index a77f19f..9ec7a75 100644
> > --- a/net/dect/mac_csf.c
> > +++ b/net/dect/mac_csf.c
> > @@ -3656,9 +3656,11 @@ void dect_mac_irc_tick(struct dect_transceiver *trx)
> >  
> >         switch (trx->state) {
> >         case DECT_TRANSCEIVER_UNLOCKED:
> > -               /* maintain scan until clock is running */
> > -               irc->rx_scn = dect_next_carrier(0x3ff, irc->rx_scn);
> > -               dect_set_carrier(trx, DECT_SCAN_SLOT, irc->rx_scn);
> > +               if (net_random() > 0x7fffffff) {
> > +                       /* maintain scan until clock is running */
> > +                       irc->rx_scn = dect_next_carrier(0x3ff, irc->rx_scn);
> > +                       dect_set_carrier(trx, DECT_SCAN_SLOT, irc->rx_scn);
> > +               }
> >                 break;
> >         case DECT_TRANSCEIVER_LOCK_PENDING:
> >                 irc->si.ssi.pscn = dect_next_carrier(0x3ff, irc->si.ssi.pscn);
> > 
> > 
> > However, I don't get a lock just in PP mode, if I don't use the monitor
> > flag:
> > 
> > [607158.216667] com_on_air_pci 0000:02:04.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
> > [607158.216679] com_on_air_pci 0000:02:04.0: setting latency timer to 64
> > [607158.241899] com_on_air_pci 0000:02:04.0: Loading firmware ...
> > [607158.788708] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
> > [607192.974449] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
> > [607219.881092] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
> > [607232.329542] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
> > [607263.615645] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
> > [607283.483168] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
> > [607287.032726] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
> > [607298.211337] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
> > [607307.220212] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
> > [607370.522330] identities information: e: 0 class: 0 emc: 11d3 fpn: 0f371 rpn: 0
> 
> The timings indicate that it only receives very few frames from the
> FP. Is it possible that it's operating in ECO-mode?

The Fritzbox 7270 supports ECO-mode, however I have disabled that
feature in the settings dialog. However, I cannot check if ECO-mode is
really disabled.

Anyway, I will upgrade my firmware to the latest version, perhaps the
bug has been fixed and the new firmware operates properly now.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.osmocom.org/pipermail/linux-dect/attachments/20101115/b271f948/attachment.bin>


More information about the linux-dect mailing list