Is there a way to temporarily disable the cellular modem of making a “transmission”. I know I can use Cellular.Off() and Cellular.On() to turn it completely off/on however each time I would do that it would have to re-establish a connection from scratch. Is there a way through AT commands or some other method to simply momentarily prevent transmission for a short duration say 1-2 seconds. My thought is to disable transmission for a very short duration such that it doesn’t have to re-establish the connection from scratch. I’d simply disable it, transmit via the other radio (which I have full control over), and then allow the cellular modem to transmit again. I’m looking at 1-2 seconds of inhibited cellular modem every 5 minutes or so. Is this as simple as not calling Particle.Publish() during this time and block any calls/don’t use Particle.Functions()? I assume there is still transmissions that occur in the background for the keep alive right?
The reason I’m asking is I would like to add another radio to the Boron and develop a product from it. This then would require FCC testing. I’m still learning the FCC implications of co-located FCC certified modules, however from what I can tell, the FCC testing requirements would be significantly less if I can guarantee the two radios would not transmit simultaneously even if co-located.
I’m going to guess that it’s not possible. There are two parts to this, however.
It probably would be possible to prevent things like publish, keep-alive, ACKs, etc. from going out. It might require a modification to Device OS, however.
The bigger issue is that the transmitter is also doing stuff behind the scenes to maintain the cellular connection. I suspect those transmissions would also be an issue for the FCC, and I could not find anything that looked like there’s any control of it on the u-blox AT command set. There is a possibility that I missed it, however.
Thanks @rickkas7 I figured that was the answer but thought it was worth asking anyhow. I might be able to “get by” with using the Cellular.off() when needing to broadcast via the other radio but it certainly isn’t desirable. I also would make it much less frequent (maybe once every 1 hour or even 12 hours instead of every 5 minutes). It certainly isn’t desirable and adds a lot of extra headaches to deal with the one off scenarios. It’s either that or I go through full FCC certification (would rather not do that especially with a Boron. I wasn’t quite ready to bite off going to a b-series SoM but if I was going to go through the entire FCC certification I think I would go that route for “production grade”.
I assume if an AT command existed for something like this it would be somewhere in this manual right? Or what u-blox AT Command set should I be looking at with a fine tooth comb for the Particle Boron LTE version? This? https://www.u-blox.com/sites/default/files/SARA-R4_ATCommands_UBX-17003787.pdf
Yes, that’s the manual I looked at. I also tried a few Google searches, but I didn’t find anything useful.
AT+CFUN=0 temporarily disables transmit and receive (i.e. airplane mode). AT+CFUN=1 restores full functionality.
CFUN=0 does not persist across a reset. If you need it to persist, use AT+CFUN=4 instead. That’s persistent airplane mode.
Very good! So it’s possible through AT Commands… @picsil - Have you used these commands before? If it’s a momentary (1-2 seconds) of “airplane mode” and then back to full functionality does it have to re-establish a connection from scratch?
Some of the language used in the u-blox manual makes me think it’s still “deregisters” and the connection would have to start over from scratch similar to a cellular.Off() command.
a network deregistration is needed: issue the AT+CFUN=0 command to
deactivate the protocol stack
In any case, I’ll give this a try and see what I can learn.
@picsil - Well it was worth a shot… however AT+CFUN=0 completely resets the session so it immediately disconnects upon AT+CFUN=0 and has to renegotiate a new session with AT+CFUN=1 even with 1 second between the commands. So for all practical purposes, it’s behavior is pretty much the same as Cellular.Off() and Cellular.On(). If anyone else has some ideas I’m all ears… otherwise I may go down a different route and deal with the extra headaches of not being able to transmit with both simultaneously on demand, rather wait for less frequent opportune times to transmit over the additional radio by using cellular.off() and cellular.on().