Project

General

Profile

Actions

Feature #5417

open

S/T (S0) ISDN BRI adapter with VCXO / GPS-DO

Added by laforge 5 months ago. Updated 13 days ago.

Status:
In Progress
Priority:
Low
Assignee:
Category:
tdm-core
Target version:
-
Start date:
01/24/2022
Due date:
% Done:

30%


Description

So.. As part of the Community_TDMSS7_Network, offering PRI is nice but most people will have BRI equipment (modems, ISDN-TA, small home PBX, ...) that they'd be interested in attaching.

Doing this with COTS ISDN adapters is not an option, as we cannot control their clock to match the master clock of the TDMoIP network.

I've been brainstorming a potential design and validated component availability. Currently I'm thinking of something like this

  • CologneChip XHFC-2SU (2-port S0) controller IC, operated in NT mode
    • available from stock at MOQ-160 from CologneChip
  • Matching dual magnetics.
    • digikey + mouser have a few pulse parts still in stock (low qty): T5007
    • Sumida has stopped all production
    • Talema has 30 weeks lead time
    • UMEC still has some stock of UT20795-5MTS, I'm putting a 250 unit reel on sysmocom stock right now
  • clocking
    • 10 MHz VCXO (optional external 10 MHz input in case somebody already has GPS-DO around)
    • some clock divider to bring this down to 8kHz. If we have no other programmable logic or timer/counter blocks that can be used, an ATTiny clocked off 10MHz (no prescaler, counter generating interrupt every 250 cycles, divide-by-5 in software/irq-handler) approach can be used - doen in a lot of DYI 10MHz -> 1PPS designs.
    • some PWM or DAC to drive the VXCO

The more interesting question is the interface on the "Compute" side.

Possible high-level approaches:
  1. USB-attached to some Linux PC
    • more analoguous to icE1usb, but requires an additonal computer
  2. Raspi hat (or beagle or the like)
    • I'm not a big raspi fan, but they are very popular
  3. built-in Ethernet for direct TDMoIP
    • most easy to deploy, would allow people without Linux knowledge to simply plug+play

Right now I'm leaning mostly towards something self-contained with built-in Ethernet.

The major problem right now is availability of uC or FPGA.
  • STM32 are basically vanished off the planet
  • iCE40 equally not available (yes, tnt might get 100, but ...)

One thought might be to use an SAME5x (sysmocom uses that part in the sysmoOCTSIM and has some stock. It is a bit on the high-end side compared to the requirements).


Files

xhfc-2su.pdf View xhfc-2su.pdf 6.02 MB XHFC-2SU laforge, 02/06/2022 08:58 AM
xhfc2su-line.png View xhfc2su-line.png 73.1 KB laforge, 04/07/2022 05:50 PM
xhfc2su-breakout-v1.jpg View xhfc2su-breakout-v1.jpg 1.6 MB laforge, 05/19/2022 08:15 PM
krcjdhxylma.jpg View krcjdhxylma.jpg 2.94 MB manawyrm, 05/25/2022 10:38 PM
sbwvaixyeok.png View sbwvaixyeok.png 25.8 KB manawyrm, 05/25/2022 10:38 PM
gwjbeqsytvk.png View gwjbeqsytvk.png 1.5 KB manawyrm, 05/25/2022 10:38 PM
nxodmpghkas.jpg View nxodmpghkas.jpg 2.85 MB manawyrm, 05/25/2022 10:44 PM
wltvrxeaych.jpg View wltvrxeaych.jpg 3.57 MB manawyrm, 05/28/2022 09:48 PM
misdn_xhfc2su.patch misdn_xhfc2su.patch 189 KB manawyrm, 06/16/2022 01:37 PM

Checklist

  • sourcing of magnetics
  • design XHFC-2SU board to connect to ATSAMV1-XULT
  • sourcing of XHFC-2SU
  • sourcing of ATSAMV71
  • sourcing of VCXO
  • testing of xhfc2su-breakout v1

Related issues

Related to OCTOI - Osmocom Community TDM over IP - Feature #5436: BRI variant of OCTOI protocolNewlaforge01/30/2022

Actions
Actions #1

Updated by laforge 5 months ago

In terms of uC:
  • a variety of SAM4E are available with shipping dates in march/april 2022
  • Digikey has a SAMV71 in stock, but only in the 64LQFP package, TBD if we can access all the required peripherals in that package
    • also has built-in high-speed capable USB device (not that we need 480 Mbps, but we've seen the constraints of full-speed ISO transfers on modern XHCI hubs) not in 64pin package
Actions #2

Updated by tnt 5 months ago

Quick note is that for a standalone solution, if this has to work through the internet with auth/encryption and all the complexity of networking (config dhcp/manual/ipv6) ... it'll take a beefy uC.

Actions #3

Updated by laforge 5 months ago

On Mon, Jan 24, 2022 at 08:25:56PM +0000, tnt wrote:

Quick note is that for a standalone solution, if this has to work through the internet with auth/encryption and all the complexity of networking (config dhcp/manual/ipv6) ... it'll take a beefy uC.

Encryption is probably asking for too much in such a small/embedded device.

Given our existing experience with NuttX at sysmocom some years back I would consider using
NuttX as a OS, and NuttX has IPv4, DHCP and IPv6 support (although the latter may not be
entirely production-ready, I never tested it).

Actions #4

Updated by laforge 5 months ago

  • Priority changed from Normal to Low
Actions #5

Updated by laforge 5 months ago

  • SAMV71 revision A+B errata clearly states "USB is not working in 64pin LQFP package"
    • Same applies to SAME70
  • 64pin package available in various SAME70/V71 parts
  • SAMV71 in 100pin package (TQFP or BGA) not available before July 2022 @ microchip
  • SAME70 in 144pin package available as early as March 2022 (ATSAME70Q19B-AN)

So if we go with this series, we can realistically either go for 64pin (no USB) or 144pin (with USB).

Actions #6

Updated by laforge 5 months ago

  • Project changed from BBS-Revival to OCTOI - Osmocom Community TDM over IP
Actions #7

Updated by laforge 5 months ago

  • Category set to tdm-core
Actions #8

Updated by laforge 5 months ago

Actions #9

Updated by laforge 5 months ago

  • % Done changed from 0 to 10

Ok, decided to take the risk and order some SAMV71N19B in 100-TQFP which should arrive in late February 2022. As they have both Ethernet and HS-USB, we keep all our options. Flash is "only" 512k, I would have preferred 1M or 2M - but that would have meant using 64pin packages without working USB.

I did a quick Nuttx build for the V71 with lots of additional features, debugging, shell, telnet server, USB, CDC-ACM, Ethernet, IPv4, IPv6, mbedTLS, DHCP client, ... and it ended up a 260 kByte. So even with a DFU loader we should still have some space for the application.

Actions #10

Updated by laforge 5 months ago

Further review of the XHFC-2SU clock section:

  • it is not sufficient to just provide an 8kHz frame sync signal
  • we'd better clock the entire XHFC off a VC[TC]XO.
    • Ideally this would be a 24.576 MHz or 49.152 MHz one
    • However, we can also use the interenal DPLL, which according to Table 9.3/9.2 of the XHFC-2SU data sheet can deal with plenty of standard xtal frequencies from 1.8432 all the way up to 66 MHz.
    • generating the frame sync signal is not needed at all in this scenario

So we can do away with the ATtiny doing frequecy division, one less part.

We'll have to work out how the 'disciplining' of the VC[TC]XO is going to look like, preferably without requiring additional parts beyond what the SAMV71 has to offer, which is plenty, in theory:
  • Four Three-Channel 16-bit Timer/Counters (TC)
  • Two 4-channel 16-bit PWMs
  • One 2-channel, 12-bit, 1 Msps-per-channel Digital-to-Analog Controller (DAC)
  • One Analog Comparator Controller (ACC)

The 16-bit TCs can be chained, see Figure 50-2 of the SAM E70/S70/V70/V71 manual. So we can basically create one 32bit counter, which is far sufficient count a few megaherz of clock cycles between two 1PPS signals, if we configure the PPS to do the 'trigger'. Software should then be able to steer the XO voltage via some control loop.

Actions #11

Updated by laforge 5 months ago

one interesting topic is the question of providing phantom voltage to attached end user devices like phones.

The specs require a voltage between 34..42V.

One could of course go the "usual" way of using a dc/dc upconverter to generate that voltage. The problem is that most DC/DC converter modules are very hard to source these days (and expensive, of course).

So an alternative approach could be to use an 48V power supply, and then use a DC/DC to 3.3V for the digital side, and use a linear regulator for generating 34..42V from the 48V. This would also open the possibility fo doing a PoE input. This way it would be a PoE-powred Ethernet-to-BRI converter, actually pretty neat.

In the end, I think the PoE PD and phantom voltage supply could be a separate, optional daughter board, given the involved cost.

Actions #12

Updated by laforge 5 months ago

I'm currently focusing on the PRI side, so don't expect too much progress here.

As a first step, I am planning to build an "XHFC-2SU breakout board", with connectors that allow it to be hooked up to an ATSAMV71-XULT evaluation board. This first board will contain the XHFC-2SU, the magnetics, matching networks, and the VCTCXO. It will not contain any power supply / phantom voltage or the SAMV71 yet to keep things simple. Having that board would allow somebody to already work on the software, which is also a non-trivial undertaking.

Actions #13

Updated by laforge 5 months ago

laforge wrote in #note-10:

Further review of the XHFC-2SU clock section:

  • it is not sufficient to just provide an 8kHz frame sync signal
  • we'd better clock the entire XHFC off a VC[TC]XO.
    • Ideally this would be a 24.576 MHz or 49.152 MHz one
    • However, we can also use the interenal DPLL, which according to Table 9.3/9.2 of the XHFC-2SU data sheet can deal with plenty of standard xtal frequencies from 1.8432 all the way up to 66 MHz.
    • generating the frame sync signal is not needed at all in this scenario

Seems I was wrong [again]. From Section 5.2.7 and Figure 5.5 of the XHFC-2SU data sheet:

The 192 kHz bit clock as well as the 8 kHz frame clock are derived from FSYNC in NT mode. This signal is either F0IO input or F1_7 (see register R_SL_SEL7 and Figure 6.5 on page 229).

so it is sufficient to provide the 8kHz clock.

Actions #14

Updated by laforge 5 months ago

  • Checklist item sourcing of magnetics added
  • Checklist item design XHFC-2SU board to connect to ATSAMV1-XULT added
  • Checklist item sourcing of XHFC-2SU added
  • Checklist item sourcing of ATSAMV71 added
Actions #15

Updated by laforge 3 months ago

There's an open source mISDN driver for the XHFC-SU at https://github.com/ISDN4Linux/mISDN/blob/master/drivers/isdn/hardware/mISDN/xhfc_su.c which can be used as inspiration when writing the firmware.

Actions #16

Updated by laforge 3 months ago

I did the initial footprints for magnetics + XHFC, as well as the schematics work for the line interface from XHFC chip through all the passives, magnetics and to the RJ45 sockets, see https://gitea.osmocom.org/electronics/osmo-small-hardware/src/branch/laforge/xhfc/xhfc-breakout

Actions #17

Updated by laforge 3 months ago

  • Status changed from New to In Progress
Actions #18

Updated by laforge 2 months ago

  • Checklist item sourcing of VCXO added
  • Checklist item design XHFC-2SU board to connect to ATSAMV1-XULT set to Done
  • % Done changed from 20 to 30
The XHFC-2SU breakout board has beem making good progress. The board contains
  • XHFC-2SU
  • VCXO with analog control voltage input
  • Header with SPI / !IRQ / !RST of the XHFC-2SU (to connect to some uC board)
  • all the analog interface circuitry bteween magnetics and XHFC-2SU
  • 2x magnetics
  • Jumper blocks for cross-over NT/TE mode
  • separate 2pin headers for feeding an external phantom voltage source into the S0 ports
  • 2x RJ45 for the two different S0 interfaces

It's a 100x50mm 2-layer PCB. No parts smaller 0603 were used to facilitate convenient hand-soldering.

I'm going to add some more test pads, a power LED, an LDO and some minor bits and will order some first prototype PCBs from aisler later today.

Actions #19

Updated by laforge 2 months ago

ok, xhfc-breakout v1 has been completed. pushed to master of osmo-small-hardware.git and ordered 3 prototype PCB (matches the 3x XHFC-2SU samples I have).

Actions #20

Updated by laforge about 1 month ago

parts have all arrived, I started assembly of the first prototypes but then got pre-empted by important work :/

Actions #21

Updated by laforge about 1 month ago

3 Prototypes have been assembled:

xhfc2su-breakout-v1.jpg

I've also updated the schematics with some fixes (just parts values) and comments. See https://gitea.osmocom.org/electronics/osmo-small-hardware/src/branch/master/xhfc-breakout for EAGLE sources and updated PDF rendering.

The assembled prototypes differ from the schematic in one way: R5/R6/R21/R22 are 0R but should be 3R3 (as the "universal NT/TE mode" assembly option is chosen).

Boards will be sent to manawyrm and tmwawpl while I'll be on holiday. Let's hope they can get them to work and I didn't make too many errors in the design or assembly.

Actions #22

Updated by manawyrm about 1 month ago

First signs of life:
The ALE/SPI_INV pin was created in the EDA, it's connected to a net, but that net doesn't go anywhere.
That pin is quite important and need to be grounded, though. After grounding, the chip can be talked to! :)

My mod: krcjdhxylma.jpg

Reading the R_CHIP_ID register:

Actions #23

Updated by manawyrm about 1 month ago

Current dev setup

Actions #24

Updated by laforge about 1 month ago

Sorry for that ALE pin bug, and thanks for finding it.

Actions #25

Updated by manawyrm about 1 month ago

Here's the XHFC-2SU breakout board successfully doing a phone call with mISDN:
https://www.youtube.com/watch?v=OGJuU-rzIjY

:)

Had some expert kernel dev help from tSYS to get this working, mISDN was using some spinlocks in places and wasn't really compatible with talking via SPI, but that was pretty easily fixable.
Now back to DAHDI...

Actions #26

Updated by manawyrm about 1 month ago

OK, both S0 interfaces work fine as well.

The attached photo shows the jumper configuration for NT-mode, connected to a phone with a 1:1 cable.

Actions #27

Updated by laforge about 1 month ago

Congratulations!

Actions #28

Updated by tmwawpl about 1 month ago

I've updated my board to fix the ALE/SPI_INV issue as instructed by manawyrm. Then connected XHFC board to PC using SPI provided by Bus Pirate. There is communication with HFC chip so board works.
Also NuttX is now running on my STM32F4Discovery board, basic networking works (ping, dhcp client).
TODO:
- communicate over SPI with XHFC chip using NuttX

Actions #29

Updated by laforge 25 days ago

manawyrm wrote in #note-22:

First signs of life:
The ALE/SPI_INV pin was created in the EDA, it's connected to a net, but that net doesn't go anywhere.
That pin is quite important and need to be grounded, though. After grounding, the chip can be talked to! :)

Fixed in the schematics+layout in e039fe159034e2982a2ac954dd187ea9694ba252

Actions #30

Updated by laforge 13 days ago

manawyrm would you mind explaining a bit further the software setup you managed to create?

Actions #31

Updated by manawyrm 13 days ago

laforge Sure!
Currently, the XHFC-breakout is working with mISDN on a Raspberry Pi.
This patch (applies to a current raspberrypi master-branch Linux kernel) will add support for the xhfc-breakout device (will get automatically detected from the device tree).
I wrote a device-tree overlay which will get the kernel to load the appropriate mISDN driver automatically.
The patch is pretty ugly, but I attached it anyways :)

I was using misdn's testlayer3 utility for most of my testing so far.
My main target was to get the hardware up and running (up to a phonecall), so I could verify the board, layout and chip itself as working :)

The next step (at least for me) would be to write a DAHDI driver.

I've started to try and port the functionality of the one DAHDI driver that already used a XHFC device (wctdm24xxp), but that was a bad idea. The code structure/layout of that driver is way to complex and messy, as it's designed to accept daughter cards for various connection methods.
So the best way forward is probably to write a clean DAHDI driver.

That could interface with Yate and probably osmo-trunkdev/osmo-e1d to make something that could be used to connect to OCTOI already :)
I was busy with the dayjob in the past couple of weeks (we're getting ready for a big launch) and thus haven't had much time (and piece of mind) to sit down and try to write something like that.

Before going any further with the embedded system, there would probably need to be some way of transporting BRI data over the OCTOI protocol? Not sure where you'd start with that. I don't think it's really helpful to port something like mISDN to an embedded platform, just to rip it all out again and replace it with the UDP interfacing code?

Actions #32

Updated by laforge 6 days ago

  • Checklist item sourcing of XHFC-2SU set to Done
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)