Hardware Projects » E1/T1 Hardware Interface (including icE1usb) » osmo-e1d

Thank you for response )

I've tried with next version:

smo-e1d> show version
osmo-e1d 0.4.0.1-6cd9-dirty (osmo-e1d).
(C) 2019-2022 by Sylvain Munaut, Harald Welte and contributors

osmo-e1d> show interface
Interface #0 (***), Driver: usb
 GPS-DO: mode=DISABLED, fix=FALSE, state=DISABLED antenna=UNKNOWN, tune=0/0, freq_est=0

# lsusb -d 1d50:6145 -v 2> /dev/null | grep bcd
  bcdUSB               2.00
  bcdDevice            0.03
        bcdDFUVersion                   1.01

Thank you for response )

I've tried with next version:

osmo-e1d> show version
osmo-e1d 0.4.0.1-6cd9-dirty (osmo-e1d).
(C) 2019-2022 by Sylvain Munaut, Harald Welte and contributors

osmo-e1d> show interface
Interface #0 (***), Driver: usb
 GPS-DO: mode=DISABLED, fix=FALSE, state=DISABLED antenna=UNKNOWN, tune=0/0, freq_est=0

performer wrote in #note-2:

Thank you for response )

I've tried with next version:
[...]

Sorry again for no follow-up. As long as the issue is in state "feedback" and assigned to you (and not to me!) I will not see it when looking at "my issues". Please always assign back to me if you want some input from me.

Is this still a problem? I think we need more details about your setup to understand. Did you try on any other computer or linux version? I there anything non-standard about your setup (like VMs, ...)? What USB host controller (see lspci) on what kind of computer are you experiencing this?

I have no permissions to reassign issue here.

We used different hardware, mostly RasPi 3, 4, CM4 with current release of Raspberian and x86-64 running Ubuntu. Also I‘ve tried to use Debian 11 VM unter Parallels on Intel Mac.

We have to retest it again with fresh versions.

Btw, here is our usage description - https://wiki.tetrapack.online/books/tetra/page/e1t1-interface

On Sun, Dec 03, 2023 at 02:53:27PM +0000, performer wrote:

I have no permissions to reassign issue here.

thanks for reporting this. It seems the permission to edit your own issue was not present
for a non-member of the project. fixed now. Sorry for the related inconvenience.

We used different hardware, mostly RasPi 3, 4, CM4 with current release of Raspberian and x86-64 running Ubuntu. Also I‘ve tried to use Debian 11 VM unter Parallels on Intel Mac.

this is rather strange as we have a number of users of icE1usb on a variety of hardware (including rpi3/4) and nobody has so far reported any related issue.

Are you sure the E1 line is not actually dead? Normally this error should only happen if there is no E1
signal, i.e. no E1 bit clock received from the equipment attached to the port (tetra BTS in your case). It
should resolve by itself as soon as a signal is received on the port. You can normally provoke this by
un-plugging the cable (error messages about dead link start) and re-plugging it (error messages about dead link stop).

laforge wrote in #note-6:

Are you sure the E1 line is not actually dead? Normally this error should only happen if there is no E1
signal, i.e. no E1 bit clock received from the equipment attached to the port (tetra BTS in your case).

5 different e1usb devices cannot have dead the same E1 line simultaneously :)

It starts to work after restart (or several restarts) of e1d. I made a workaround that detects availability of traffic on unix-socket and restarts a daemon.

#!/bin/bash

PREFIX=/opt/TetraPack

for INSTANCE in $(ls $PREFIX/*.env | xargs basename -s .env)
do
  SERVICE=dummy\@$INSTANCE
  STATE=$(systemctl show $SERVICE --property=ActiveState)
  STATE=${STATE#*=}

  if [ "$STATE" == "failed" ] || [ "$STATE" == "deactivating" ]
  then
    systemctl status $SERVICE | grep "E1 connection timeout" > /dev/null
    if [ $? -eq 0 ]
    then
      RESTART=true
    fi
  fi
done

if [ "$RESTART" == "true" ]
then
  echo Restarting Osmo E1D
  systemctl restart osmo-e1d
fi

[Service]
; system.service
ConditionPathExists=/tmp/osmo-e1d.ctl
ExecStartPre=+/bin/chmod o+rw /tmp/osmo-e1d.ctl
ExecStopPost=+/opt/TetraPack/failure.sh

Hi performer,

On Sun, Dec 03, 2023 at 06:23:06PM +0000, performer wrote:

5 different e1usb devices cannot have dead the same E1 line simultaneously :)

Does this only occur with one specific vendor/model of E1 equipment (Tetra BTS in your case), or
have you seen this also when connecting to other equipment? It might be that the Tetra BTS
stops generating a valid E1 signal for some time. I'm just guessing here.

A good test case would be to use a loopback cable that feeds the Tx pair of the RJ45 back to the
Rx pair of the same RJ45 connector. In this case, the icE1usb will receive anything it
transmits. If the problem still occurs in that situation, we are sure it is not related to
the behaviour of external equipment.

That occurs only on start of e1d and never happen when BTS (Motorola CTS, it seems Harald has it on his storage) connected to another DTMoIP equipment.
Will check with EBTS when get it.

Latest versions of E1D and icE1usb behave much more stable. Using versions of 23.12.23
Now both CTS and EBTS are rock stable connected to Raspberry CM4 under Debian 12