You need to use muxtx when in mux mode.
Yes.
I'm not 100% sure what muxtx does not in mux mode.
Bad things. Probably an unrecognised command (or perhaps a crash).
Obviously smashing all of that into one metric isn't a great thing to do, and probably not all of it is needed in metrics? The cell identifier, protocol and frequency look useful. Simcom's documentation for this says
It does look like useful information, and trivial to process. Perhaps two metrics: One for the common stuff (<System Mode>,<Operation Mode>,<MCC>-<MNC><LAC>,<Cell ID>) - perhaps formatted nicely Another for the per-protocol stuff (the remainder of the line, raw)
I also discovered that the modem is not stable powered by USB on my desk. It disconnects from the cell network or reboots every few minutes. It has been stable for many hours since I turned the 13.5V power supply back on.
Yes, that is very common. Need a powered USB hub. Regards, Mark.
On 19 Aug 2018, at 6:38 PM, Tom Parker <tom@carrott.org> wrote:
Hi,
I've been experiencing poor cellular connectivity with my v3.0 prototype. The changes Mark made a while ago to recover from various corner cases improved things a lot but outside my house it is often disconnected even though my cell phone has reasonable signal strength. I tried to extract extra information from the modem and also force it to use 2G since my OVMS v2 is rock solid in the same location on the same carrier. I learnt some things:
I'm using the possibly slightly out of date https://simcom.ee/documents/SIM5360/SIMCOM_SIM5360_ATC_EN_V0.24.pdf which doesn't require a login to get.
Sending AT+CNMP=13 is documented to force it to use 2G, but instead it puts the modem into a boot loop. It does the START +CPIN: READY dance ending with PB DONE and then goes back to START. It never responds to the first AT commands we send it, and power cycling does not fix it. I went down many rabbit holes to fix this, it looks a lot like not enough power (I'm powering via USB) but adding 13V to the CAN bus port didn't fix it. Removing the simcard fixed it, but this supported the power theory which turned out be wrong. Sending AT+CNMP=2 as soon as it sends START does result in OK and pust it back into auto mode and stops the boot loop.
I spent a while hacking simcom.cpp to send commands of my choice to the modem, but got tired of that and thought, there _must_ be a way to do this interactively! I traced the tx code paths and found that there are two ways:
simcom tx AT+CNMP? simcom muxtx 3 AT+CNSMOD?
You probably need at least verbose logging to see the responses. You need to use muxtx when in mux mode. I'm not 100% sure what muxtx does not in mux mode.
After I sorted out the modem boot loop I added polling of AT+CPSI? and hooked the result up to a metric (and also logged it). I can see which cell tower I am connected two and on what frequency and protocol, below is it switching cell id and frequency:
I (26562395) simcom: CPSI: +CPSI: WCDMA,Online,530-01,0x0778,xxx,WCDMA IMT 2000,306,10588,0,9.0,95,24,20,500 I (26592445) simcom: CPSI: +CPSI: WCDMA,Online,530-01,0x0778,yyy,WCDMA 900,62,3086,0,5.0,94,27,21,500
Obviously smashing all of that into one metric isn't a great thing to do, and probably not all of it is needed in metrics? The cell identifier, protocol and frequency look useful. Simcom's documentation for this says
If camping on a 2G cell: +CPSI:<System Mode>,<Operation Mode>,<MCC>-<MNC><LAC>,<Cell ID>,<Absolute RF Ch Num>,<RxLev>,<Track LO Adjust>,<C1-C2> If camping on a 3G cell: +CPSI:<System Mode>,<Operation Mode>,<MCC>-<MNC>,<LAC>,<Cell ID>,<Frequency Band>,<PSC>,<Freq>,<SSC>,<EC/IO>,< RSCP >,<Qual>,<RxLev>,<TXPWR>
I'm not sure what else is useful to parse into metrics? Maybe the network numbers for roaming? See page 140 of the pdf mentioned above for more details.
I haven't yet used this information to try to tell what is wrong with my poor connectivity problem.
I also discovered that the modem is not stable powered by USB on my desk. It disconnects from the cell network or reboots every few minutes. It has been stable for many hours since I turned the 13.5V power supply back on. _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev