LTE Cat 4 Cell Modem Card - Framework Community

Ok guys, My name is Tim and I would like to introduce myself. I am an engineer with over 20 years experience in making innovative designs from military vehicle modifications to commercial tools. After seeing Framework for the first time I have fallen in love with their vision and want to help see their concept get off the ground. To that idea I decided to do what I do best…

For more information, please visit Getspeed.

Design Something.

So I present my first design for framework. The Cat 4 LTE modem.

There were a few design challenges with this one, including:

• Finding a modem module to fit in the housing
• Specifying available components
• Getting an antenna connection

Now there is no way we can fit the antenna in this module as well for sizing as well as I don’t have the facilities to test antenna efficiency. But I have provided 2 MMCX connectors for a primary and a diversity antenna(optional).

The main features of this module are:

• Using a Nano Sim Card
• Fully fits within the expansion card dimensions (*mostly, the antenna connectors required an extra 0.5mm length, I swear you won’t see it )
• Transmit LED Between the antenna connectors
• Cat4 Speeds (150 Mbit/s downlink — 50 Mbit/s uplink)

Verizon support:

Want more information on 4G LTE Dongle? Feel free to contact us.

• LTE bands B2, B4, and B13
• UMTS bands B2 and B5

AT&T Support

• LTE bands B2, B4, B5, and B17
• UMTS bands B2 and B5

The goal of this module is to provide a fully contained modem within the outline of the expansion module. Things like faster connections/Integrated antenna/other provider support will require a larger module.

When fully inserted the SIM card is hidden below the rail of the card.

• {Image of the card fully inserted ISO View - not included due to new user restrictions}
• {Image of the card fully inserted Front View Wireframe - not included due to new user restrictions}

PCB Views:

• {Image of the PCB Top Side - not included due to new user restrictions}
• {Image of the PCB bottom Side - not included due to new user restrictions}

I am working on getting quotes and other required information to apply for the Developer program. I am also looking for ideas for my next card development. Please provide some feedback and let me know what else you guys would like me to work on.

@Framework I have ordered a card sample to look at your production assembly methods, I saw that it shipped and am looking forward to disassembling it. but this module has a tight fit, I am looking for tips on how to add the “lid” to this with how thin it needs to be over the module. I will include this in my Developer Program application but figured I would ping you here, too.

Project Status:

For more 4G WiFi Routerinformation, please contact us. We will provide professional answers.

Would you consider an AT&T Velocity (rebranded ZTE MF923) battery operated mobile hotspot a dongle? If so, I use it semi regularly connected to the usb port of a WNDRv1. The micro usb port of the Velocity provides data and power from the router, so the hotspot is always powered. I simply change the WAN port to 4G, and away we go, usually. Once in a while I might have to reboot one or the other to get FT to acquire an IP address on the wan port, but never too problematic.

If this device is not considered a dongle, you may disregard this message.

Added to the Dongle compatbility table.

I simply change the WAN port to 4G, and away we go, usually. Once in a while I might have to reboot one or the other to get FT to acquire an IP address on the wan port, but never too problematic.

I wrote the following script and I add it to the USB and NAS -> USB Support -> Hotplug script section when tethering because of this issue:
Bash:

if [ "${ACTION}" = "add" ]
then
    service wan restart
elif [ "${ACTION}" = "remove" ]
then
    dhcpc-release
fi

It isn't perfect (I believe it experiences a series of "add" events in a row when connecting, which causes a series of slow WAN connect/disconnects), but I find this outcome (taking a couple of minutes to fully connect) far better than the alternative of losing connectivity and it not automatically (and always) reconnecting itself at an unattended location.

I wrote the following script and I add it to the USB and NAS -> USB Support -> Hotplug script section when tethering because of this issue:
Bash:

if [ "${ACTION}" = "add" ]
then
    service wan restart
elif [ "${ACTION}" = "remove" ]
then
    dhcpc-release
fi

It isn't perfect (I believe it experiences a series of "add" events in a row when connecting, which causes a series of slow WAN connect/disconnects), but I find this outcome (taking a couple of minutes to fully connect) far better than the alternative of losing connectivity and it not automatically (and always) reconnecting itself at an unattended location.

I think this is a good starting point but we need to work on the script. As you rightly mention this assumes that the USB device it's a 4G gateway e.g. we dn't want to restart the wan when a USB storage is plugged. I don't have any 4G device with me where I am now but could you see if monitoring the dmesg before and after 4G is connected gives any important hints? A must have is the USB port number for devices with multiple USBs. All I see is the following message regardless of what kind of device is connected:
Code:

Feb 3 17:05:06    kern    info    kernel    usb 2-1: new high speed USB device using ehci_hcd and address 4
Feb 3 17:05:10    kern    info    kernel    usb 2-1: USB disconnect, address 4

• Each time the device is plugged back in, address increments by one.
• Executing service wan restart simulates clicking the [Connect] button on the Overview page, something the firmware does initially upon entering tether mode, but fails to redo automatically upon connecting a tethering device to USB.
• Connecting and disconnecting an Android in its default storage mode or in tether mode results in exactly the same two messages shown above.
• Connecting a USB flash drive results in the same USB connect message, followed by a series of SCSI, SDA, and SD messages as the volume is detected, mounted, and mapped. Obviously the firmware can tell that they're different, but is not sharing that information in the debug log.
• The messages shown in the debug log and returned by dmesg are identical, although the latter is missing source and time information.
• While properly filtering the USB connect event to just tether/modem devices would be ideal when it comes to adding this missing autostart functionality to the firmware itself, I believe a more important fix to my script would be to have it somehow set a flag, that a timer would take care of maybe 10 seconds later. That way, multiple connect events could be filtered out.
• I believe the multiple connect events I was referring to might be caused by the 50' USB extension cable I'm using on the setup in question (not shown above). I believe it has two active USB repeaters in it, which show up on a PC as USB hubs. The firmware might be seeing each repeater and the as separate devices, each with its own ID and connect event, resulting in repeated, painfully slow restarts of the wan service over a minute or two upon connecting. Again, decoupling the actual event(s) from the service wan restart command with a timer would allow these events to pass by harmlessly and be covered by a single restart command. Conversely, filtering to execute the command only on a tether/modem device would also solve the problem and is arguably the "more correct" solution.

pedro:

I plugged a Novatel usb730l into my RT-AC68U running FT .1 . It still doesn't work. So I sent you a PM with the log contents.

Any help would be appreciated. We haven't got any new 4G dongles to work in a long time, and I'd love to get mine working.

If anyone else can suggest anything, here's the switch4g part from the logs:

Dec 31 19:00:28 unknown user.notice switch4g[909]: 4G MODEM not found in USB_ModeSwitch database - already switched? Loading modules...
Dec 31 19:00:28 unknown kern.info kernel: usbcore: registered new interface driver cdc_wdm
Dec 31 19:00:28 unknown kern.info kernel: usbcore: registered new interface driver qmi_wwan
Dec 31 19:00:29 unknown user.notice switch4g[909]: 4G MODEM WAN (qmi_wwan) not found ...
Dec 31 19:00:29 unknown kern.info kernel: usbcore: deregistering interface driver qmi_wwan
Dec 31 19:00:29 unknown kern.info kernel: usbcore: deregistering interface driver cdc_wdm
Dec 31 19:00:30 unknown kern.info kernel: usbcore: registered new interface driver cdc_ether
Dec 31 19:00:31 unknown user.notice switch4g[909]: 4G MODEM WAN (cdc_ether) not found ...
Dec 31 19:00:31 unknown kern.info kernel: usbcore: deregistering interface driver cdc_ether
Dec 31 19:00:33 unknown kern.info kernel: usbcore: registered new interface driver cdc_ether
Dec 31 19:00:33 unknown kern.info kernel: usbcore: registered new interface driver cdc_ncm
Dec 31 19:00:33 unknown kern.info kernel: usbcore: registered new interface driver cdc_wdm
Dec 31 19:00:33 unknown kern.info kernel: usbcore: registered new interface driver huawei_cdc_ncm
Dec 31 19:00:34 unknown user.notice switch4g[909]: 4G MODEM WAN (huawei_cdc_ncm) not found ...
Dec 31 19:00:34 unknown kern.info kernel: usbcore: deregistering interface driver huawei_cdc_ncm
Dec 31 19:00:34 unknown kern.info kernel: usbcore: deregistering interface driver cdc_wdm
Dec 31 19:00:34 unknown kern.info kernel: usbcore: deregistering interface driver cdc_ncm
Dec 31 19:00:34 unknown kern.info kernel: usbcore: deregistering interface driver cdc_ether
Dec 31 19:00:35 unknown kern.info kernel: usbcore: registered new interface driver cdc_ether
Dec 31 19:00:35 unknown kern.info kernel: usbcore: registered new interface driver cdc_ncm
Dec 31 19:00:36 unknown user.notice switch4g[909]: 4G MODEM WAN (cdc_ncm) not found ...
Dec 31 19:00:36 unknown kern.info kernel: usbcore: deregistering interface driver cdc_ncm
Dec 31 19:00:36 unknown kern.info kernel: usbcore: deregistering interface driver cdc_ether
Dec 31 19:00:37 unknown kern.info kernel: usbcore: registered new interface driver cdc_ether
Dec 31 19:00:37 unknown kern.info kernel: usbcore: registered new interface driver rndis_host
Dec 31 19:00:37 unknown daemon.info dnsmasq-dhcp[886]: DHCPDISCOVER(br0) 48:78:5e:c8:40:0b
Dec 31 19:00:37 unknown daemon.info dnsmasq-dhcp[886]: DHCPOFFER(br0) 10.0.0.7 48:78:5e:c8:40:0b
Dec 31 19:00:37 unknown daemon.info dnsmasq-dhcp[886]: DHCPREQUEST(br0) 10.0.0.7 48:78:5e:c8:40:0b
Dec 31 19:00:37 unknown daemon.info dnsmasq-dhcp[886]: DHCPACK(br0) 10.0.0.7 48:78:5e:c8:40:0b amazon-15cc2c974
Dec 31 19:00:38 unknown user.notice switch4g[909]: 4G MODEM WAN (rndis_host) not found ...
Dec 31 19:00:38 unknown kern.info kernel: usbcore: deregistering interface driver rndis_host
Dec 31 19:00:38 unknown kern.info kernel: usbcore: deregistering interface driver cdc_ether
Dec 31 19:00:39 unknown user.notice switch4g[909]: 4G MODEM WAN not found - connection process terminated!
Dec 31 19:00:41 unknown kern.info kernel: usb 2-1: new high speed USB device using ehci_hcd and address 3
Dec 31 19:01:01 unknown kern.info kernel: usb 2-1: USB disconnect, address 3
Dec 31 19:01:02 unknown kern.info kernel: usb 2-1: new high speed USB device using ehci_hcd and address 4
Dec 31 19:01:21 unknown kern.info kernel: usb 2-1: USB disconnect, address 4
Dec 31 19:01:22 unknown kern.info kernel: usb 2-1: new high speed USB device using ehci_hcd and address 5
Dec 31 19:01:42 unknown kern.info kernel: usb 2-1: USB disconnect, address 5
Dec 31 19:01:43 unknown kern.info kernel: usb 2-1: new high speed USB device using ehci_hcd and address 6
Dec 31 19:02:03 unknown kern.info kernel: usb 2-1: USB disconnect, address 6
Dec 31 19:02:04 unknown kern.info kernel: usb 2-1: new high speed USB device using ehci_hcd and address 7

IF this means the router isn't loading the driver correctly, that would be a bit of disappointing step backwards, as I believe the last release did load it properly (before pedro said he fixed things).

Thanks