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

I downgraded osmo-e1d to 785476901c0d78960e7bcd82fcc2c5535fadd70c - July 2019, i.e. long before any of my changes to make sure it is not any of my recent osmo-e1d contributions. The behavior is identical, i.e. the "Far End Block Errors Detected" message is presented, too.

It might be related to the E-bits?

ITU-T G.704 Clause 2.3.3.4 states:

In those frames not containing the frame alignment signal (see 2.3.2), bit 1 is used to transmit the 6-bit CRC-4 multiframe alignment signal and two CRC-4 error indication bits (E).
...
The E-bits should be set to "0" until both basic frame and CRC-4 multiframe alignment are established (see clause 4/G.706). Thereafter, the E-bits should be used to indicate received errored sub-multiframes by setting the binary state of one E-bit from 1 to 0 for each errored sub-multiframe.

So yeah, the gateware is definitely at fault here: * I don't set the bit properly when not aligned * I inverted them ... I naively thought E=0 meant no errors :/

There is a way to work-around in the firmware. You can disable the 'automatic mode' of setting the E bits by replacing E1_TX_CR_MODE_TS0_CRC_E by E1_TX_CR_MODE_TS0_CRC in the init code for the TX core. It will then use bits [14:13] of the buffer descriptors word to fill the E bits instead and you can set those to 1 by using something like e1_regs->tx.bd = e1f_ofs_to_mf(ofs) | E1_BD_CRC1 | E1_BD_CRC0; when filling the TX buffer descriptor.

It'd be good to confirm that this workaround works and then I'll get to actually fixing the gateware to make sure the automatic mode works as the spec requires.

update: tnt provided a firmware workaround build, and I tested it in the exact same test setup. The Cisco is now happy. tnt indicated he will be fixing the gateware at some later point.

Attaching the firmware update here for the record.

laforge wrote:

tnt indicated he will be fixing the gateware at some later point.

I didn't yet see any related updates in git. Labelling as 'stalled' for now'

This should be fixed in https://github.com/no2fpga/no2e1/commit/26d99a8519086735dd64d7167265ac88cc3aa004 which is included in the latest gateware.

Remains to be tested though

I'll be re-testing with the (supposedly long fixed) gateware against the cisco device soon.

osmoE1usb connected to cisco:

c2811-ent#show controllers E1 0/0/0
E1 0/0/0 is down.
  Applique type is Channelized E1 - balanced
  Receiver is getting AIS.
  alarm-trigger is not set
  Version info Firmware: 20090113, FPGA: 20, spm_count = 0
  Framing is CRC4, Line Code is HDB3, Clock Source is Line.
  CRC Threshold is 320. Reported from firmware  is 320.
  Data in current interval (374 seconds elapsed):
     1937 Line Code Violations, 0 Path Code Violations
     0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
     0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 374 Unavail Secs

After disconnecting the cable:

c2811-ent#show controllers E1 0/0/0
E1 0/0/0 is down.
  Applique type is Channelized E1 - balanced
  Far End Block Errors Detected
  Receiver has loss of signal.
  alarm-trigger is not set
  Version info Firmware: 20090113, FPGA: 20, spm_count = 0
  Framing is CRC4, Line Code is HDB3, Clock Source is Line.
  CRC Threshold is 320. Reported from firmware  is 320.
  Data in current interval (452 seconds elapsed):
     1939 Line Code Violations, 0 Path Code Violations
     0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
     0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 452 Unavail Secs

• loss of signal is not present when cable is inserted
• AIS is detected when cable is inserted, keeping the link state down.

Interestingly this is different from the behavior originally reported about "far end block errors"

This was a bug in some of my patches.

Cisco is now happy with current master and with lafogre/usb-hdr:

E1 0/0/0 is up.
  Applique type is Channelized E1 - balanced
  No alarms detected.
  alarm-trigger is not set
  Version info Firmware: 20090113, FPGA: 20, spm_count = 0
  Framing is CRC4, Line Code is HDB3, Clock Source is Line.
  CRC Threshold is 320. Reported from firmware  is 320.