Getting BC660K-GL running (step by step)

Hello.
I need to say that I never had a BC660K-GL in my hands before. I made my own PCB with power supply (LDO regulator from 5.0V → 3.3 V for VBAT supply, the modem chip, SIMcard socket, and a little bit of additional parts, according to the Hardware Application Guide.
The schematic can be seen here (because I am new, I cannot upload a file), so I try to place a link instead:
Here the schematic: [http://www.hantsch.co.at/_temp/Comm-Board.pdf]
Here the PCB design: [http://www.hantsch.co.at/_temp/Comm-Board-PCB.png]
From my understanding I did everything correct.

What I would expect on Power-Up (regardless if SIM is inserted or not), is some kind of life-sign, i.e. the NET_LIGHT LED could somehow blink. But there is absolutely nothing.

Can somebody, please, have a look on my schematic, if I did it correct?

Little explanation: The schematic contains two SIMcard sockets, only one of them can be soldered to PCB at a time, the difference is their size.
My mainboard (with MCU) and the COMM-Board are sitting piggyback on each other. Line RE0 (from MCU) can control the transistor for pulling /RST. Line RE1 (from MCU) does the same with PSM_EINT.

What I encountered:

  • When both boards are fully interconnected, the MCU cannot start up. It loops in the startup sequence. So my first thought was too high power consumption from BC660K-GL.
  • So I decided to only connect GND + 5V between PCBs and to measure current consumption. Surprisingly the mainboard had no issies now. Surprisingly NET_LIGHT LEDs are permanently off.
  • My thought: Possibly are the transistors for /RST and /PSM_EINT) in “ON” condition because their base is floating? Grounding both BASEs changed nothing, the NET_LIGHT is still OFF
  • I also inserted an old SIM (from an mobile phone), in case thatr BC660K-GL enforces one. Still no difference.

What I will do next is increasing the base resistors from 1k → 10k, to see if the MCU will still permanently reboot then.
Any suggestions?

Are you an individual developer or a company?

I run my own company, developing customer specific devices and solutions (hard-&software)

Herbert,
meanwhile I figured out that the BC660K-GL is causing a horrible number of interrupts on my MCU (in RX line). This caused all the troubles with MCU reboots. When disabling RX-Interrupts, the CPU runs normally because now the received garbage (or whatever the modem transmits here) is completely ignored.

So I am (slowly) getting closer to the problem, but you did not answer my question(s) in useful way yet.

It is very irritating to me that modem’s TX line (pin 17) is most of the time in LOW condition and emitting HIGH pulses in equal intervals (very fast). Whatever this is, it is not what an idle UART should do.
I sent nothing to the modem, so it should also send nothing. And the IDLE level uf UART definitely is a continuous HIGH.

Do I have to configure the modem for lower baudrate by software? The MCU I use is relatively powerful (Microchip PIC 18F67K40 @ 64 MHz), but as I use a multitasking subsystem and three UARTS in parallel, I cannot reliably handle such high baudrates because the MCU has to do lots of other things in parallel. Therefore I need a drastically lower baudrate (19200 or 38400 bps) which is still more than sufficient.
Does BC660K-GL support automatic baudrate detection or not? If not, this is an odyssee. First switch into a extremely high baud rate, send the command for lower baudrate, then re-program the MCU-UART to that lower baudrate. I don’t like that.

You did not say any word about the NETLIGHT output.
I would expect that this modem also gives a life-sign when no SIM card is inserted, or when the SIM card is not matching (i.e. for normal mobile phone). It will then not be able to connect to the network, but it is still internally operable. But I see absolutely nothing… (Transistor + LEDs are working!)

Generally the documentation says almost nothing about behavior of BC660K-GL, this does not make it easy to locate problems.

I double checked the current PCB Layout and cannot find any reason for the troubles I see. Could you, please, have a look on the schematic and PCB screenshot? Is something not wired up correctly?

Hi Rainer
We use the BC660 here, typically TXD, RXD & Reset are the only connection required. Others are interesting, but at the end of the day, not used.
One thing to note… TXD and RXD are powered down when the modem sleeps… this might be the source of noise you are seeing. Also transitions on RXD automatically wake the module which powers up the UART which activates TXD… see a loop here.
What we have done is to turn off RXD until we want to receive something (i.e. turn on TXD and RXD together). We use an ST ARM L0+ so have DMA for transmit and a custom receiver ISR, so we don’t have issues with timing, But you may need to write a driver with a focus on speed. KISS to keep it running.

Simon

Hi, Simon.
Thanks a LOT for this valuable information.

About power-down of RxD and TxD in sleep mode… Does Modem TxD enter high impedance state, or is it pulling low? In first case, a simple pull-up resistor will solve the problem as it keeps the level of MCU’s RxD high (to IDLE State). But you are right, I can also turn the receiver completely off in worst case. (Because I use CRTOS multitasking system, I don’t like turning off hardware so much, some other task could be hindered by that.)

I had a long conversation with T-Mobile Austria two days ago. The guy was talking of 350 Byte/s data transfer rate and did not recommend using TCP/IP therefore (because of overhead). What transfer speed do you usually have with NB-IoT? I would prefer using TCP/IP (over IPv4), because this already controls the data flow, while using UDP would have me to control the data flow by myself. Today I received two SIM cards for testing, but I did not test them yet. (Have to implement the modem first in my firmware).

I inserted one of them into my modem, but I was very surprised about what happened on power up.
Something does not appear to work correctly, or BC660K-GL behaved totally different to my formerly used M35 based modems.

  • The modem is definitely powered up correctly (3.3V with 200uF Tantalum + the bunch of other capacitors) and it sends a response to AT commands (so it is not in sleep|deep sleep).
  • A NETLIGHT LED is connected by a BC817 transistor. Actually not very much can be done wrong with such modem module, I think. I tested the LED by shorting E and C of the transistor. It lights up, so no faults here. The base is connected to the BC660K’s pinby a 4k7 resistor. :zipper_mouth_face:

I would expect that the LED starts blinking on power up, indicating that the BC660 starts searching for a mobile network, but it is permanently off.

Do I have to initialize the BC660 to wake it up on radio side?
My difficulty is: I do not have a BC660K module with USB or RS-232 interface to connect it to my PC (running minicom on Linux). I only have the built up PCB of my prototype device. What I meanwhile figured out is a huge difference in behavior between my formerly used Quectel M35 based modules and this BC660K module. The M35 needed a “Power Button Press” (simulated by a BC817 transistor), then it woke up and immediately tried to connect to the mobile network (also blinking its status LED). BC660 should(?) automatically wake up, but does absolutely nothing.

Can you, please, provide me details on your initialization sequence? I mean the sequence of commands you send to get the BC660 registered on radio network side. This would make my first steps in getting this BC660 operational lots easier.

From what I heard from the T-Mobile guy, all I have to do is setting the correct APN (which I was told by him). IIRC, this should be identical to the M35 module. But shouldn’t the modem do something before with its LED, too?

Rainer

Hi Rainer
Firstly… don’t pull up or down the TXD/RXD lines… Remember that transitions on TXD will cause a wake up. We don’t pull the lines and have no issues.

Secondly… ALWAYS turn hardware off… Bread and butter off low power battery. If it ain’t on, it ain’t drawing power. (see exception below) Personally, I only leave on what is necessary. Console RX, IO etc.

Exception to this is the BC660… leave it on and rely on the PSM modes. Another ‘feature’ … NB/IoT searches for comms channels on power up. In New Zealand this takes 10 minutes, in Europe, this can take up to 30 minutes. If I change provider or APN (I’ve done this for testing) 20 - 25 minutes before its ready again… that’s 20 - 25 minutes of battery drain. From what I understand, NB/IoT devices check all cell towers, and all bands for the best channels to use and the best providers so in theory, you can use a global sim and multiple providers.

I am taking MQTT (over TCP) but I am gathering a whole day of logs and sending them twice a day, we are talking 1.5k per call roughly, but because I only call every 12 hours, I (should) get 7 years of a Lithium Primary C cell.
I do notice it takes quite a few seconds to send a frame. I do need to frame balance (i.e. send 2 x 529 byte frames instead of 1009 + 49) as sometimes the frame doesn’t get through.
[163658] send: 1009
[163713] Got “+QMTPUB: 0”
[163714] send: 49
[163724] Got “+QMTPUB: 0”
[hhmmss] = 15 seconds + 10 seconds

Call time 64 seconds, 11 logs sent

Vodafone here also recommend NOT using MQTT, since it uses TCP/IP. But the company I work for use MQTT. I set timeouts, retries and version at the start so I don’t get as many failures.

With 350 bytes, I would consider UDP or COAP, both will give you a decent performance gain, but not Confirmed Delivery. you can manage this by requesting confirmation for selected entries. Don’t expect Quectel to make CoAP available, what I’ve heard is the have no flash space (or don’t see it as important) so you have to do it yourself. And Please… think of security … login, passwords, encryption.
Also be aware there is a 1024 byte character limit (512 hex bytes or 1024 ascii characters). I use BASE-64 encoding because of this limit.

I believe NetLight only pulses with a poll from the network (so you have to have a sim card as well). The BC660 spends most of its time in deep sleep and disconnected from the network, Mine is only awake for a minute every 12 hour, so you are unlikely to see anything at all.
Note: We don’t have NETLIGHT connected, so I don’t know exactly what it does and when.

My Init Sequence (simplified a bit, but all the steps are there):
Firstly bunch of AT’s at different speeds to work out the baud rate. with a reset between them (this only happens when I first power on)

send “AT\r\n” … up to 4 times to get a response
[042635] NBIOT has responded.

send “ATE=0\r\n”
[042636] Echo mode turned off successfully.

send “AT+CGSN=1\r\n”
[042636] The IMEI number is: 866207058354238.

send “AT+QCCID\r\n”
[042637] The CCID number is: 6401200307927925.

send “AT+CIMI\r\n”
[042637] The IMSI number is: 530011114927925 (53001).

send “AT+CFUN=?\r\n”
[042638] AT+CFUN=1
if not, send “AT+CFUN=1\r\n”

send “AT+QBAND=?\r\n”
[042638] Frequency bands: “3,8,28”

send “AT+CPSMS?\r\n”
[042639] send: AT+CPSMS? (“00101110”,“00000101”)
check result matches expected results. PSM is set to 2 hours past my call in time, So I control the call in

send “AT+QICLOSE=1;+QICLOSE=2;+QICLOSE=3 … \r\n”
[042640] All ports closed

send “AT+CGDCONT?\r\n”
Check returned APN, set if not correct and resent BC660

send “AT+CSQ\r\n”
[042641] Signal Strength: -97 dBm
[042642] ***** End of call 7 s (11) *****

Typically I wait 60 seconds after power up or reset before attempting this, (apart from AT\r\n baud rate detection & AT+I\r\n Identification).
After this, I wait 10 minutes before attempting sending a frame, usually attempting to connect won’t work during this time.
Once I’ve successfully call in at least once, I go straight from the AT\r\n to AT+CGDCONT?\r\n. If I fail 5 times in a row, I reset the BC660 and go through the whole sequence again (10 minutes after reset).

As you can see, I don’t change much, I don’t do any pre-configuration either. Some of the changes require a reset of the BC660 which I do via the reset line. My ISR automatically detects responses and sets flags appropriately, That way the CPU is effectively sleeping so all I have to do is send a command, and sleep until the status changes.

Note: If you get a NB/IoT SIM, it should register automatically, Set the APN via AT+CGDCONT (once) then set +CFUN=1 (also once) and its connected … but it does take 20 - 30 minutes here in NZ, not sure about Aussy so just be patient. The webinar from the UK, the guy said go make a cup of tea… I would suggest go have a beer (or coffee). My Personal experience: AT+CSQ returns 99 during this time, so no signal = trying to find a channel. I haven’t fond a way to detect its trying to find a provider/channel - but also haven’t looked very hard.

Another one… Vodafone (and Spark here) don’t hold a channel more than 3 hours. if you request a 12 hour PSM sleep, it will dump all the session info after 3 hours, For Vodafone, I send multiple AT+QMTOPEN= … at 1, 2, 4, 8 … second intervals (power of 2), usually gets through on 4th or 5th attempt. Spark require you to reset the BC660 and to re-establish the connection. If you are doing this commercial, they will have a hared APN or private APN which doesn’t forget you. Or just limit you connection interval to a maximum of 2.5 hours or similar.

As far as waking the BC660… just send multiple AT\r\n until you get an OK response with 500ms between (I send up to 10, but it never requires that many)…

Simon

Simon, thank you so much for this details.
You need to know that energy saving currently is of absolutely not importance. This devices will be run in daily used cars, so I have almost unlimited power. But - of course - it is never wrong to save power…
Yesterday I ordered some CH340 based USB → Serial converters. This will allow me to connect the communications board to my Linux Workstation and use minicom for first steps.

My RX-Interrupt procedure is is currently working in a way that it records all input in a local string-buffer (as long as there is room, or until I receive a , id ignored). When is received, I export this buffer to a global buffer, set a semaphore (signal), and clear the interrupt-buffer.
The signal wakes up the task processing received data, then the task goes into “waiting for next signal” mode again.

I hope that “ATE0” gets the BC660 into a mode where no multiline output (with in between occurs. If so, I have to change my interrupt procedure to record only when a flag is set, but then also . The culprit is: Then it is lots harder to detect the end of a transmission, I would have to use timeouts, which is still not reliable.

I read a command (datasheet for AT commands not at hands at the moment), that there is a command for sending data. IIRC, this command also requires the number of bytes.

  • Does this command receive a block of data and return immediately (while data is still being sent by the modem), or does the modem respond after the last byte was physically sent? I will prefer using TCP/IP because it implements a correct transmission (so bytes come out on remote side in correct order. With UDP or other I would have to control that by myself, that is wasting resources.
  • You mentioned you have to split data in smaller packets before sending. Well, I will send data records (Pascal language type “record”) one by one. One record will be approx 60-80 byte , so I am in safe size. I will send the record + CRC in HEX format, then I await an acknowledge from remote system, then I mark this record as “sent”. This loops until all records are sent.
  • From my estimation I am on the safe side, even with this slow NB-IoT transmission speed. I get a new record every 30 seconds. This record is kept in F-RAM (256kByte, non volatile). A second task tries to keep this F-RAM empty. This way no data will be lost, even when there is a temporary connection loss. And transmission is much faster than recording, so it can catch up in reasonable time.
  • What I am unsure about is: I am trying to send from moving cars. The guy from T-Mobile told me that NB-IoT is not designed for moving from one radio cell to another. If this is the case, is there a way to work around that? As mentioned before, I do a local data buffering. I can record for up to ~3200 records in F-RAM, this is ~1600 minutes (= ~27hours). I am sure that there will be sufficient time within one radio cell to transmit a bigger bunch of records. But I have no experience on how long I am offline before be connected from a different cell… I also don’t know if I have to re-initiate something when appearing in a new cell, of if this happens automatically.

Can you enlighten me a bit, please?

Rainer.

Don’t forget power = heat… and cars are very hot already (I designed an eRUC (Road User Charges) for automotive previously). And even cars have their power down modes… everyone go “Cars have big batteries” but leave a modern car for a month in winter and see if it starts. OK probably will - but my eRUC could also be mounted on a trailer… with a much smaller battery - and left for 6 months).

You are probably thinking the wrong way about the comms… its basically poll / reply send a packet, receive a packet, so having a rx task that is not part of a tx/rx pair just means you need more states to work out what response is for what state. It is better to send a command, wait for a response move to next state.

With MQTT, each MQTT frame is 1 BC660 frame. I believe the same is true of UDP & TCP. This means you can send/receive hex frames just by looking for the \r\n at the end. A \r\n without any preceding chars - just ignore. (and DONT send \r\n as part of text data … you will simply confuse yourself)

I usually set a 300 millisecond timer to wait for a response for most commands, longer as per the data sheet.
For Unsolicited Responses, 32 seconds timeout. Sleep 500ms, look for “+QMT” with a ‘\n’ following it somewhere in the buffer. If not found, continue to loop (sleep first). I then expand the test for “QMTRECV:”, “QMTOPEN:”, “QMTPUB:”, etc. This way I frame the result and extract it for processing with a call back routine. But I always start sending a frame with the receive index set to 0 (start of buffer), that way I don’t have to deal with buffer wrap. (MQTT trick - return 3rd or last entry, whichever comes first since that’s the command status).

But ATE=0 - it simply suppresses what you send, so you don’t have to filter what you just send, just process responses (with lots of \r\n). Standard code - I’ve done this since the 1990’s

When sending data, there are 2 methods, 1 has length, 1 doesn’t.

After sending the frame wait for an initial response (OK), then a delayed Conformation (SEND OK/FAIL) (15 seconds from my last post). Note … Poll / Reply… Send command, get OK but the delayed response is also there for some commands so two responses to look for (e.g. +QIOPEN, +QICLOSE, +QISEND, +QIPING, +QIDNSGIP).
UDP actually wastes less than you might thing… if you consider 10 seconds to be the round trip, you ack data you need to ack, login, time, last data received etc. One thing that may cause an issue… I adjusted the time for MQTT, extended it to 30 seconds & 3 retires. TCP doesn’t have that option.

if you are moving (haven’t tried this) then you may not be-able to send or receive. Remember 20 - 30 minutes to re-establish… I don’t know if its automatic, I’ve not tried moving, I suspect you will need to reset the BC660 and re-establish a connection (which will be automatic after a reset) I haven’t tried this, but I do take my unit between Masterton and Wellington with a power-down & reset in between… seems to work reliably. And seems to only require 10 minutes to reestablish (but only 2 sites).
I suspect you actually need a 4G modem which is designed for this (What I used with eRUC) Worst case… 20 minutes loss of signal with NBIOT… so it can only send once it reaches it destination. If you consider 10 seconds per frame - that’s too many seconds to count assuming you don’t get a failure and have to tear down the link and re-establish.

Simon

Hi, Simon.

About heat … I am more concerned about temperatures inside cars caused by sun. Therefore I am a bit scared about a complete power shutdown, in this case also the cooling fan cannot work, so the device mounted behind the wind shield on top of dashboard might exceed temperature limits. Therefore I designed a “SmartSupply”, a supply with integrated MCU, step-down regulator, and the possibility to control the power line to connected devices. It also senses connection (15), switched (+), so attached devices can change their behavior depending of this information. But they also can send a “Turn me off for … minutes”. If switched “+” gets on, this power-off is aborted.
As LCDs don’t like temperatures >70°C. All electronics in my system is literally cold. I use switching power converters and run everything on 3.3V (some few exceptions use 5.0V). My total power consumption is currently less than 200mA, and this includes all parts running in full mode. But I also can turn off parts and also the entire system for predefined time. (Main unit tells power supplying unit to turn power off for … minutes. A PIC 12F1840 and a switching regulator from 12|24V → 10V, then without load, is all what remains on, and a converter without load draws almost no power.)
This way I can sync complete power-off with day/night, and I also can wake up from time to time to transmit data.

About comm:
I have multiple layers of Rx.

  • First layer is the interrupt procedure. It moves received characters int a larger interrupt_Rx_buffer to keep the UART-FIFO free. This is vital. When is received, it is ignored. When is received and something is inside interrupt_Rx_buffer, this buffer is transferred to an external Rx_Buffer and interrupt_Rx_buffer is cleared, plus a signal for data received is set. If interrupt_Rx_buffer isempty, nothing happens.
  • Second layer is a task, processing this received data. So there I am able to send a command and wait (with timeout) for the signal, without wasting CPU time in a waiting loop (thanks to CRTOS).

Meanwhile I read the documentation of AT commands (basic ones and those for TCP/IP) again. Meanwhile, thanks to your additional input, I see some light at the end of the tunnel… :sweat_smile:

  • My plan is to monitor the status of the modem (if registered or not), signal quality, … every few seconds. This way I can detect a lost registration (i.e. because I left the cell). In this case I will initiate a re-registration. This will keep the modem “online”. - And I make the connection status internally available.

  • The comm task will watch the level of available data. If a specific level is reached, it will connect to the server and send all data, then close the connection again. I also close the connection when connection is lost by any reason.

  • Because I have a local F-RAM of 256kB, no data will be lost, as all Tx-Data is recorded there and sent from there record-by-record by another task. So this F-RAM acts as huge buffer for up to 27 hours of data, but it will be kept as empty as possible. In case an interruption occurs (connection dropped), transmission will restart on first not confirmed record.

  • Did you ever try? Can I send pings while I have a TCP/IP connection open?

Hi, Simon.

Meanwhile I connected the modem to a USB-TTL adapter to do tests with minicom (terminal program on Linux).

So far it looks very nice.
I use this sequence for init:
at ← Wake modem up. Repeat until “OK” comes back.
ate0 (Turn echo off)
at+qledmode=1 (Turn NETLED ON)
at+qcgdefcont=“IP”,“m2m.public.at” (assign APN and use IPv4 only)
at+qsclk=0 (Turn Sleep mode off to have UART fully operational)

Strange, that I was not able to resolve DNS, etc. So I sent this command:
at+qrst=1 Cause a restart

And now I could contact an SMTP server and receive his welcome message.
at+qiopen=0,0,“TCP”,“**********************”,25,25
OK

+QIOPEN: 0,0

+QIURC: “recv”,0,103,“220 xxxxxxxxxxxxxxxxxx ESMTP Sendmail 8.15.2/8.14.5/SuSE Linux 0.8; Thu …”

There arise following questions:
Does the BC660K forget all settings on power down (do I have to do the entire startup init every time), or does it remember settings (if so: which ones?)

What I did not really understand (please explain):
I use at+qiopen to connect to a TCP service. This gives me a response, containing the initial welcome of the SMTP server (as an example), with a prefix containing “recv” and number of characters.
Is this only during opening a connection? So I will have to parse everything coming from the modem? Or do I have to poll the modem to get further received data?

Finally I use “at+qiclose=0” to close the connection.

1/ It remembers all the settings, they are stored in flash (there are a few which aren’t, but it says so in the manual). My code only does the setup once, it then checks if config has been changed by the user (APN, etc) as a just in case. Subsequent calls start with AT\r\n then Check Carrier.

I always assume that the MQTT parameters change, so I always set the version and timeouts.
MQTT data sheet: “Characteristics: The command takes effect immediately. The configuration will not be saved.”

TCP/IP datasheet: “Characteristics: These commands take effect immediately. The configurations will be saved to NVRAM automatically and remain valid after deep-sleep wakeup.”

2/ Normally you will send a command to the server, then get a URC (Unsolicited Result Code). This is in fact the server sending a frame to you and isn’t related to the initial connect. In this case, you have connected to a SMTP server and its sent you an announcement. You then need to send a HELO and you will get another URC response. So you send → wait for URC → send → wait for URC etc. You will have to handle both “recv” and “closed” URCs as both are valid responses. “incoming” URC - just a pain (probably a hack attempt unless you do a “TCP LISTENER”).

3/ Yep… you can try to send a AT+QICLOSE=0 but you will probably get a URC “closed” first. You will need to handle both events. TCP/IP is a little friendlier than MQTT, look for “+QIURC:”, skip any space, skip next quote then is it “closed”, “recv” or “incoming” … handle appropriately (i.e. “incoming” => AT+CLOSE=n" :slight_smile: .)

Hi, Simon.
Is NV-RAM a real NV-RAM (meaning keeping its content also over long periods of complete power off / VBAT = 0V), of is this to be understood as “battery buffered RAM” only?
If this is flash as in microcontrollers, this kind of storage has very limited number of writes So a full init on every power-up should be prevented then? I do not want to “write the flash to death”.

So from your answer I understand that a AT+QRST=1 and an external RESET both have the same effect, the MCU inside the modem does a restart. Hereby I found out that this ends in loss of powersaving mode (so this setting is lost), This is very nasty, because the UART is off in any powersaving mode, so the first character is lost every time. → Turning off powersaving by “at+qsclk=0” to stop this

Well, I can use this (by probing “at+qsclk?”) to do a full re-init if it does not return “+QSCLK: 0”, this will at least reduce number of writes to NVRAM|FLASH.

I really wonder why quectel didn’t implement a “AT&W” command, as all analog modems have. This command writes all current settings to non volatile memory. So setup once, finally send “AT&W”, and you are done. Anyway, it is as it is, hope that NVRAM is not written to death within some years of operation, where power up/down happens several times a day…


Do you know a setting to suppress this right-padding of URCs? I implemented code to suppress multiple succeeding characters in my RX interrupt routine. Otherwise I would have to reserve a big buffer to also get the trailing <"> into it, because parsing the received URC does happen outside of interrupt procedure. This reduces RAM Buffer size to data + URC-Prefix.
I also suppress empty lines (only , is always filtered out), they don’t cause a trigger for input processing.

Now I found out that even keeping the UART on is not sufficient at all. Regardless if TCP/IP or UDP, the modem appears to disconnect on radio side after some inactivity (we talk of ~10 seconds)? Compared to the roundtrip time of approx 4-6 seconds this is dangerously tight. When model falls into this mode, data from server don’t get out on modem’s side.
Does this mean I have to actively send something from modem to server to keep the connection active? In this case I will have to implement a “software-ping” to be answered by the other side only to keeüp up some traffic?
Or can I adjust the timeout to i.e. some minutes or turn it off at all?