[Ovmsdev] OVMS v3.3 hardware
dexter at expeedo.de
Mon Dec 13 15:56:04 HKT 2021
To add another data point here: my production module (running
Last boot was 1093166 second(s) ago
Time at boot: 2021-11-30 17:07:33 CET
OVMS# cell status deb
Network Registration: RegisteredHome
Signal: -85 dBm
User Data: 0
FIFO overflows: 3277
Buffer overflows: 0
Parity errors: 0
Frame errors: 0
Driver Buffer overflows: 0
Mux: Status up
Open Channels: 4
Framing Errors: 1713
RX frames: 1181428
TX frames: 21380
Last RX frame: 1 sec(s) ago
PPP: Connected on channel: #2
GPS: Connected on channel: #1
Mark, maybe you can reproduce the effect by enabling the modem GPS.
Am 13.12.21 um 08:19 schrieb Mark Webb-Johnson:
> I can see some improvements:
> 1. If we get a HW FIFO overflow in MUX mode, there is little point in
> continuing. Probably simplest to reset the modem at that point.
> 2. At the moment, we pickup on various failures (like no MUX traffic,
> unable to make cellular connection, etc) and reset the modem. But
> I too have seen cases where the cellular connection can’t be made,
> that only a module reset seems to fix.
> Perhaps the problem is in the async driver? Better to reset that
> as well?
> 3. Hardware flow control would be nice, but sadly we simply don’t
> have the GPIOs for it. We only have two free unused, and they are
> desperately needed for expansion modules. The MUX protocol does
> have a software flow control mechanism, but I am not sure if that
> would help.
> 4. I wonder why you are getting HW FIFO overflows? I am not seeing these.
> Attached are draft 3.3 schematics. I have one change outstanding on
> these (I want to re-label CAN as CAN1..CAN3, rather than the existing
> CAN0..CAN2, to better match the firmware labelling), and then will
> Regards, Mark.
>> On 12 Dec 2021, at 6:10 AM, Craig Leres <leres at xse.com
>> <mailto:leres at xse.com>> wrote:
>> I've made a tiny bit of progress with my sim7600a ppp issue.
>> First I realized that I could now run the master branch. The first
>> test I did with my dev/7600 actually stayed connected to ppp for more
>> than 14 hours... I went looking for differences in my for-v3.3 and
>> master builds and discovered my for-v3.3 tree was still using
>> wolfssl. So I thought I had found the problem until 12 hours later
>> when the dev unit lost ppp again.
>> I also see that it's possible to get ppp back up without rebooting by
>> powering cell down (power cell off), waiting for that to complete,
>> and then powering back up.
>> I went looking for additional things to log. I have cellular,
>> cellular-modem-auto, and cellular-modem-factory set to verbose and
>> gsm-mux and gsm-ppp set to debug. What else would be helpful?
>> I was reviewing this thread and found this:
>> On 9/6/21 23:28, Michael Balzer wrote:
>> > I also added counters for these, you can query them with the "simcom
>> > status debug" command:
>> >> OVMS# sim stat deb
>> >> Network Registration: RegisteredHome
>> >> Provider: congstar
>> >> Signal: -97 dBm
>> >> State: NetMode
>> >> Ticker: 73099
>> >> User Data: 0
>> >> *** HW FIFO overflows: 21*
>> >> Buffer overflows: 0
>> >> Mux
>> >> Status: up
>> >> Open Channels: 4
>> >> *** Framing Errors: 24*
>> >> Last RX frame: 1 sec(s) ago
>> >> RX frames: 151452
>> >> TX frames: 5472
>> >> PPP: Connected on channel: #2
>> >> GPS: Connected on channel: #1
>> >> Status: enabled
>> Indeed I see one fifo overflow on my dev (which has lots ppp one time
>> since boot):
>> OVMS# cell status debug
>> MODEM Status
>> Model: SIM7600
>> Network Registration: RegisteredRoaming
>> Provider: AT&T Hologram
>> Signal: -83 dBm
>> Mode: LTE,Online
>> State: NetMode
>> Ticker: 1434
>> User Data: 0
>> FIFO overflows: 1
>> Buffer overflows: 0
>> Parity errors: 0
>> Frame errors: 0
>> Driver Buffer overflows: 0
>> Mux: Status up
>> Open Channels: 4
>> Framing Errors: 0
>> RX frames: 1864
>> TX frames: 78
>> Last RX frame: 0 sec(s) ago
>> PPP: Connected on channel: #2
>> GPS: Connected on channel: #1
>> Status: enabled
>> Time: enabled
>> I'm not sure if modem::modem() gets called when you power down/up the
>> modem so I don't know if m_err_uart_fifo_ovf has been zero'd since boot.
>> On 9/6/21 18:35, Mark Webb-Johnson wrote:
>> >> Is it too soon to add the v3.3 and v1.3 pdfs to the source tree?)
>> > Yes, we haven’t finalised those, or gone through certification yet.
>> > We’ll release the v3.3 main board and modem layouts and schematics when
>> > that is complete (probably November/December timeframe).
>> I was thinking if I had the v3.3 modem schematic I could upgrade my
>> boards to have uart hardware flow control. (I'm guessing if I had
>> this I would not expect to see fifo overflows?)
>> Would it be useful for me to setup a way for you (Mark) to connect to
>> my dev unit and interact with it while it is in the failed state?
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 203 bytes
Desc: OpenPGP digital signature
More information about the OvmsDev