Skip to product information
1 of 4

IOT Bots

LTE CAT-M1 / NB-IOT / EGPRS GNSS Feather Compatible shield

Regular price $54.95 USD
Regular price Sale price $54.95 USD
Sale Sold out

qTop BG95-M3 LTE/GNSS AFC Shield is Feather Compatible shield to be used for DIY IOT project together with Adafruit Feather Compatible IOT board to get cellular connectivity and location info for the system developed.


The qTop shields dimensions are not the same as Adafruit Feather boards and qTop shields are a little bit bigger. Please check the dimensions at picture below.


From interface connection perspective, it is compatible with and could be connected to any Adafruit Feather Compatible IOT boards. It works well even with ESP8266 Feather limited GPIOs boards - some action to be done to get it working with that board, some PCB jumpers should be reconnected.

This qTop Cell Modem shield works "out of the box" with all ESP32 Feather like boards - for basic operations it uses as default connection two control GPIOs (PWR_ON and MODEM_ON), and regular Feather UART pins and power for sure.

iotbotscom-qtop-cell-quectel-bg96-afc-adafruit-feather  iotbotscom-qtop-cell-quectel-bg96-afc-feather-esp32

Our design allows to connect almost all modem UART, GNSS UART and status pins to IOT board (RTS, CTS, DTR, DCD, RI, STATUS). To get it done PCB jumpers connection should be changed: PCB jumper connection bridge should be cut/removed and unconnected pads of jumper should be electrically connected by soldering.


The most of modem interface pins (UART, USB) could be reached using PCB control pads. Even modem FW could be updated through the Quectel FOTA or USB pads on PCB.

GNSS UART pins could be connected to IOT board as separate UART using PCB solder jumpers as well. So, we can have two independent UARTs for communicating with modem and GNSS receiver.

The main qTop BG95-M3 LTE/GNSS AFC Shield components highlighted at picture below:


And let us share the functional diagram of qTop BG95-M3 LTE/GNSS AFC Shield and give some brief functional modules description:


The core of the shield is Quectel BG9-M3 modem.

BG95-M3 is an embedded IoT (LTE Cat M1, LTE Cat NB1 and EGPRS) wireless communication module. It provides data connectivity on LTE-TDD/LTE-FDD/GPRS/EDGE networks, and supports half-duplex operation in LTE networks. It also provides GNSS functionality to meet customers’ specific application demands.

Two u.FL connectors are used for internal or external Antennas (LTE and GNSS). Shield provides 3,3VDC power   for active GNSS antenna.

Shield supports nano-SIM card to be inserted into Hinged Lid SIM Card Holder type located at the top of PCB. All SIM-card traces are ESD-protected.

Network indication LED, located in the center of the edge of the board lets observe modem network status.

TPS63020 Buck-Boost Converter is used to power modem, so shield is fully functional even with input voltage drops down to 3.3 V.

DC/DC output voltage (3,95V) is also used to power LDO, which provides 3,3 voltage for the level translators, OD logic IC and active GNSS antenna to be connected.

Level translators are used to shift voltage levels between IOT board with 3,3V signals and 1,8V levels used by modem logic.

All IOT-BOTS.COM qTop shields has device ID feature - each qTop shield has integrated EEPROM chip with UID feature. EEPROM is preprogrammed by manufacture (IOT-BOTS.COM) with shield type and info, so IOT controller with appropriate FW loaded, at power up time could identify type of the shield and configures FW to work with. So, no needs to re-flash IOT controller with new FW if you want to change shield, for example, to change wireless connectivity from LTE to LoRa : just turn power off, replace a shield and turn power on - system will recognize new HW connected and start working with that device. UID feature could be used by End User as particular device identification (for sure, IMEI could be used as well).

OD logic is simple gate IC used to convert push-pull RI modem signal to open-drain logic to be compatible with Q_INT line of qJam interface - so many different devices (sensors, actuators, modems, etc) interrupt outputs could be connected to single line to be used by IOT controller to react on system or external events.

And finally, to bring more value for our qTop products, each qTop shield (except GNSS shields) supports qJam connectivity system : it is developed by us, tiny 6-pin connecting system, which allows End User to easily bring small I2C devices (sensors, actuators, system devices, memories) to the IOT solution to be developed. Need just put qJam compatible device into qJam connector of the controller board - no cables, soldering or wires required. It has power (3,3V), I2C bus, Q_INT open-drain interrupt line and Q_IO GPIO line to be used by qJam device as additional control or status signal.

So, any qJam compatible device could be located at the top of the shield to bring more feature to the IOT solution or project you are working on.

We have started working on shield documentation and FW part already and we do our best to get them accurate and usable as much as possible. We will publish User Manual, schematic and Arduino sketch at our qTop BG96 Campaign github sooner. 

qTop BG96 LTE/GNSS AFC Shield will be delivered together with internal LTE and GNSS antennas.


Initial Demo was run on qTop BG96 LTE/GNSS AFC Shield with LTE and GNSS internal antennas connected and BME280 gJam sensor.


Arduino log could be seen below:
 - After power up UID chip is detected and shield info received;
 - next step : to check that qJam sensor is connected : BME280 sensor found and data received;
 - and final setup() step is modem on.

In the loop:
 - getting BME280 sensor data;
 - collecting modem / network status;
 - requesting GNSS info;
 - opening TCP/IP session;
 - publishing info received to a cloud;
 - closing session opened;
 - waiting for 3 sec.



We have done field test as well. We have found that qTop GNSS functionality works fine as designed. BTW, at pic below could be found that some points are out of road - the data was obtained, but due to weak GSM coverage in this area, not sent to the cloud. This issue is easily fixed by saving all reports received in Serial Flash and sending them to the cloud as soon as connection established. But this Demo did not have such option.


More Information


ThingsBoard Local Condition Monitoring Demo