For the 4G modem options we need to go through FCC, CE, and ROHS certification. Minimising/eliminating the changes to the main board simplifies this (and brings down the exorbitant costs) but if there is anything urgent / necessary, now is the time to do it.
The goal here is to maintain 100% compatibility with existing OVMS main boards, to keep this is a simple and relatively cheap upgrade of the modem board.
So far, I have come up with this minimal list:
Main board v3.3: Improve soldering of micro USB port. Bigger solder pads, and more solder to secure it better.
Modem board v1.3: Add support for SIM7600 module.
Modem board v1.3: Fix support for DTR sleep/awake support.
Is there anything else required for this update?
Regards, Mark.
On 8/16/21 10:30 PM, Mark Webb-Johnson wrote:
Is there anything else required for this update?
I'd like to volunteer for hardware testing of the SIM7600 capable version of the modem board. I have a US version of the SIM7600 module I can solder onto a bare board (and can easily deal with board-to-board connectors and support components).
Will there be any effort to support single wire can? I know you can use a 2-wire can to communicate on a single wire bus but there is the question about being able to wake up the vehicle if the can chip is not the dedicated single wire version?
(The beefed up micro usb connector sounds great)
CraigCraig,
We plan to use SIM7600G R2 chip. That is very similar to SIM5360 we currently use, but is multi-band and can cover both EU and US frequencies with one module. It is more expensive than the band-specific SIM7600A and SIM7600E, but certification costs for one single product (vs two) will be much cheaper, and logistics simpler for everyone.
I think the current modem board should already support SIM7600 modules. The sample I have is the same board design.
The issue is primarily firmware support. The for-v3.3 branch had so many problems with esp32 firmware lwip library messing up. But time is short, so I am thinking of just applying this as a small extension to the existing master firmware branch (adding a quick check for modem type, and then hard-coded support where necessary to cope with modem type differences).
Single Wire CAN is possible using that board design from Marko Juhanne, I think? If there is a requirement, we could make an optional expansion board for that (in a similar way to what we did for K-line).
Regards, Mark.
On 17 Aug 2021, at 1:59 PM, Craig Leres <leres@xse.com> wrote:
On 8/16/21 10:30 PM, Mark Webb-Johnson wrote:
Is there anything else required for this update?
I'd like to volunteer for hardware testing of the SIM7600 capable version of the modem board. I have a US version of the SIM7600 module I can solder onto a bare board (and can easily deal with board-to-board connectors and support components).
Will there be any effort to support single wire can? I know you can use a 2-wire can to communicate on a single wire bus but there is the question about being able to wake up the vehicle if the can chip is not the dedicated single wire version?
(The beefed up micro usb connector sounds great)
Craig
Mark,
I had the impression we've had more than expected "modem not/stopped working" issues. Is that impression wrong, or didn't those cases share a hardware cause? I was wondering if that could be related to a voltage regulator issue (e.g. https://www.openvehicles.com/node/2855).
Any chance to fix the missing HW flow control on the modem UART connection?
Will v3.3 automatically be built using the latest ESP32 WROVER, i.e. with the revision 3 ESP32 including the hardware SPIRAM fix?
Regards, Michael
Am 17.08.21 um 07:30 schrieb Mark Webb-Johnson:
For the 4G modem options we need to go through FCC, CE, and ROHS certification. Minimising/eliminating the changes to the main board simplifies this (and brings down the exorbitant costs) but if there is anything urgent / necessary, now is the time to do it.
The goal here is to maintain 100% compatibility with existing OVMS main boards, to keep this is a simple and relatively cheap upgrade of the modem board.
So far, I have come up with this minimal list:
Main board v3.3: Improve soldering of micro USB port. Bigger solder pads, and more solder to secure it better.
Modem board v1.3: Add support for SIM7600 module.
Modem board v1.3: Fix support for DTR sleep/awake support.
Is there anything else required for this update?
Regards, Mark.
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Michael,
- I had the impression we've had more than expected "modem not/stopped working" issues. Is that impression wrong, or didn't those cases share a hardware cause? I was wondering if that could be related to a voltage regulator issue (e.g. https://www.openvehicles.com/node/2855 <https://www.openvehicles.com/node/2855>).
I have had just three reports of modem module not working at 12V, but working at 5V. On two, the issue was the power regulator chip blown on the modem board. I don’t think there is anything inherently wrong there - probably just a faulty component or power surge.
- Any chance to fix the missing HW flow control on the modem UART connection?
I don’t think we have enough GPIOs. Perhaps later when/if ESP32 S3 becomes suitable?
- Will v3.3 automatically be built using the latest ESP32 WROVER, i.e. with the revision 3 ESP32 including the hardware SPIRAM fix?
They normally build each batch with the latest. I haven’t checked for a while, so will check one from the last batch I received, and let you know. We can request this, but it will depend on stock.
Regards, Mark.
On 17 Aug 2021, at 3:31 PM, Michael Balzer <dexter@expeedo.de> wrote:
Signed PGP part Mark,
I had the impression we've had more than expected "modem not/stopped working" issues. Is that impression wrong, or didn't those cases share a hardware cause? I was wondering if that could be related to a voltage regulator issue (e.g. https://www.openvehicles.com/node/2855 <https://www.openvehicles.com/node/2855>).
Any chance to fix the missing HW flow control on the modem UART connection?
Will v3.3 automatically be built using the latest ESP32 WROVER, i.e. with the revision 3 ESP32 including the hardware SPIRAM fix?
Regards, Michael
Am 17.08.21 um 07:30 schrieb Mark Webb-Johnson:
For the 4G modem options we need to go through FCC, CE, and ROHS certification. Minimising/eliminating the changes to the main board simplifies this (and brings down the exorbitant costs) but if there is anything urgent / necessary, now is the time to do it.
The goal here is to maintain 100% compatibility with existing OVMS main boards, to keep this is a simple and relatively cheap upgrade of the modem board.
So far, I have come up with this minimal list:
Main board v3.3: Improve soldering of micro USB port. Bigger solder pads, and more solder to secure it better.
Modem board v1.3: Add support for SIM7600 module.
Modem board v1.3: Fix support for DTR sleep/awake support.
Is there anything else required for this update?
Regards, Mark.
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Michael,
- Will v3.3 automatically be built using the latest ESP32 WROVER, i.e. with the revision 3 ESP32 including the hardware SPIRAM fix?
They normally build each batch with the latest. I haven’t checked for a while, so will check one from the last batch I received, and let you know. We can request this, but it will depend on stock.
Down the rabbit hole of detecting chip revision…
I checked a sample from the latest batch, and get:
OVMS: OVMS WIFI BLE BT cores=2 rev=ESP32/1
Esptool flash_id: Detecting chip type... ESP32 Chip is ESP32D0WDQ5 (revision 1) Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None Crystal is 40MHz Device: 4018 Detected flash size: 16MB
Boot log: I (925) psram: This chip is ESP32-D0WD I (925) spiram: Found 64MBit SPI RAM device I (925) spiram: SPI RAM mode: flash 40m sram 40m I (928) spiram: PSRAM initialized, cache is in low/high (2-core) mode.
I suspect that our old IDF is not detecting the latest revision (because it was released after our firmware).
The raw espfuse command on an old module shows:
CHIP_VER_REV1 Silicon Revision 1 = 1 R/W (0x1) CHIP_VER_REV2 Silicon Revision 2 = 0 R/W (0x0) CHIP_VERSION Reserved for future chip versions = 0 R/W (0x0) CHIP_PACKAGE Chip package identifier = 0 R/W (0x0)
Running against the sample from the latest batch shows:
CHIP_VER_REV1 Silicon Revision 1 = 1 R/W (0x1) CHIP_VER_REV2 Silicon Revision 2 = 0 R/W (0x0) CHIP_VERSION Reserved for future chip versions = 2 R/W (0x2) CHIP_PACKAGE Chip package identifier = 1 R/W (0x1)
BLK0: 00000000 2a6cbad0 0074a803 0000a200 00001231 00000000 00000004
Using the latest IDF espefuse v3.1, against the sample from the latest batch shows:
CHIP_VER_REV1 (BLOCK0): Silicon Revision 1 = True R/W (0b1) CHIP_VER_REV2 (BLOCK0): Silicon Revision 2 = False R/W (0b0) CHIP_VERSION (BLOCK0): Reserved for future chip versions = 2 R/W (0b10) CHIP_PACKAGE (BLOCK0): Chip package identifier = 1 R/W (0b001) MAC_VERSION (BLOCK3): Version of the MAC field = 0 R/W (0x00)
BLOCK0 ( ) [0 ] read_regs: 00000000 2a6cbad0 0074a803 0000a200 00001231 00000000 00000004
So, I guess it is still rev 1, but it seems a different rev 1 than the older modules? I’m confused….
I’ll check with the supplier and ask for him to try to source rev 3 in future. However, it seems we are going to have to bite the bullet at some point and undertake the massive task of moving to the latest IDF to take advantage of everything they’ve improved in the past couple of years.
Regards, Mark.
On 17 Aug 2021, at 3:55 PM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
Signed PGP part Michael,
- I had the impression we've had more than expected "modem not/stopped working" issues. Is that impression wrong, or didn't those cases share a hardware cause? I was wondering if that could be related to a voltage regulator issue (e.g. https://www.openvehicles.com/node/2855 <https://www.openvehicles.com/node/2855>).
I have had just three reports of modem module not working at 12V, but working at 5V. On two, the issue was the power regulator chip blown on the modem board. I don’t think there is anything inherently wrong there - probably just a faulty component or power surge.
- Any chance to fix the missing HW flow control on the modem UART connection?
I don’t think we have enough GPIOs. Perhaps later when/if ESP32 S3 becomes suitable?
- Will v3.3 automatically be built using the latest ESP32 WROVER, i.e. with the revision 3 ESP32 including the hardware SPIRAM fix?
They normally build each batch with the latest. I haven’t checked for a while, so will check one from the last batch I received, and let you know. We can request this, but it will depend on stock.
Regards, Mark.
On 17 Aug 2021, at 3:31 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Signed PGP part Mark,
I had the impression we've had more than expected "modem not/stopped working" issues. Is that impression wrong, or didn't those cases share a hardware cause? I was wondering if that could be related to a voltage regulator issue (e.g.https://www.openvehicles.com/node/2855 <https://www.openvehicles.com/node/2855>).
Any chance to fix the missing HW flow control on the modem UART connection?
Will v3.3 automatically be built using the latest ESP32 WROVER, i.e. with the revision 3 ESP32 including the hardware SPIRAM fix?
Regards, Michael
Am 17.08.21 um 07:30 schrieb Mark Webb-Johnson:
For the 4G modem options we need to go through FCC, CE, and ROHS certification. Minimising/eliminating the changes to the main board simplifies this (and brings down the exorbitant costs) but if there is anything urgent / necessary, now is the time to do it.
The goal here is to maintain 100% compatibility with existing OVMS main boards, to keep this is a simple and relatively cheap upgrade of the modem board.
So far, I have come up with this minimal list:
Main board v3.3: Improve soldering of micro USB port. Bigger solder pads, and more solder to secure it better.
Modem board v1.3: Add support for SIM7600 module.
Modem board v1.3: Fix support for DTR sleep/awake support.
Is there anything else required for this update?
Regards, Mark.
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Here's what I see when I ssh into one of my esp32 upgraded units:
Welcome to the Open Vehicle Monitoring System (OVMS) - SSH Console
Firmware: 3.2.016-260-g17a37c50/ota_1/main
Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/3The /3 tells me it's the V3 version of the esp32 module.
CraigOn 8/17/21 8:26 PM, Craig Leres wrote:
Here's what I see when I ssh into one of my esp32 upgraded units:
Welcome to the Open Vehicle Monitoring System (OVMS) - SSH Console Firmware: 3.2.016-260-g17a37c50/ota_1/main Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/3
The /3 tells me it's the V3 version of the esp32 module.
Also: this fix was needed for the integrated SJA1000 CAN controller for V2 chips and above:
https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/c79c...
CraigWow. I’m impressed.
I’ll talk to the manufacturer and see if we can source rev 3 chips for the next batch and onwards.
Regards, Mark.
On 18 Aug 2021, at 11:26 AM, Craig Leres <leres@xse.com> wrote:
Here's what I see when I ssh into one of my esp32 upgraded units:
Welcome to the Open Vehicle Monitoring System (OVMS) - SSH Console Firmware: 3.2.016-260-g17a37c50/ota_1/main Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/3
The /3 tells me it's the V3 version of the esp32 module.
Craig
Mark,
it seems Fasttech now tells customers the EU kit is discontinued, quote from their response:
We are sorry to tell that item sku 9642828 is discontinued. We won't sell it.
That's: https://www.fasttech.com/p/9642828
Is v3.3 that near to production, or is that once again nonsense made up by Fasttech?
Thanks, Michael
Am 19.08.21 um 08:37 schrieb Mark Webb-Johnson:
Wow. I’m impressed.
I’ll talk to the manufacturer and see if we can source rev 3 chips for the next batch and onwards.
Regards, Mark.
On 18 Aug 2021, at 11:26 AM, Craig Leres <leres@xse.com> wrote:
Here's what I see when I ssh into one of my esp32 upgraded units:
Welcome to the Open Vehicle Monitoring System (OVMS) - SSH Console Firmware: 3.2.016-260-g17a37c50/ota_1/main Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/3The /3 tells me it's the V3 version of the esp32 module.
Craig
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
A little of both. Fasttech are out of stock of EU kits (but they do have stock of US kits). Open energy monitor have EU kits still available.
Nothing discontinued yet, although will likely be before year end, and replaced with sim7600 version. Just too hard to get simcom 3G components any more.
Regards, Mark
On 23 Aug 2021, at 9:08 PM, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
it seems Fasttech now tells customers the EU kit is discontinued, quote from their response:
We are sorry to tell that item sku 9642828 is discontinued. We won't sell it.
That's: https://www.fasttech.com/p/9642828
Is v3.3 that near to production, or is that once again nonsense made up by Fasttech?
Thanks, Michael
Am 19.08.21 um 08:37 schrieb Mark Webb-Johnson:
Wow. I’m impressed.
I’ll talk to the manufacturer and see if we can source rev 3 chips for the next batch and onwards.
Regards, Mark.
On 18 Aug 2021, at 11:26 AM, Craig Leres <leres@xse.com> wrote:
Here's what I see when I ssh into one of my esp32 upgraded units:
Welcome to the Open Vehicle Monitoring System (OVMS) - SSH Console Firmware: 3.2.016-260-g17a37c50/ota_1/main Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/3
The /3 tells me it's the V3 version of the esp32 module.
Craig
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Hello all. I had very noisy readings of the 12v ADC. I tried to play with calibration values, but no luck with it. Eventually I have connected 0.1 µF capacitor to the ADC input, like described at "Minimizing Noise" article: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/pe... It might be worth considering this modification for the next hardware version.
вт, 17 авг. 2021 г. в 08:31, Mark Webb-Johnson <mark@webb-johnson.net>:
For the 4G modem options we need to go through FCC, CE, and ROHS certification. Minimising/eliminating the changes to the main board simplifies this (and brings down the exorbitant costs) but if there is anything urgent / necessary, now is the time to do it.
The goal here is to maintain 100% compatibility with existing OVMS main boards, to keep this is a simple and relatively cheap upgrade of the modem board.
So far, I have come up with this minimal list:
Main board v3.3: Improve soldering of micro USB port. Bigger solder pads, and more solder to secure it better.
Modem board v1.3: Add support for SIM7600 module.
Modem board v1.3: Fix support for DTR sleep/awake support.
Is there anything else required for this update?
Regards, Mark.
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Sounds reasonable and sensible. I will add it to the list.
Regards, Mark.
On 17 Aug 2021, at 3:56 PM, Alexander K <alexander.kiiash@gmail.com> wrote:
Hello all. I had very noisy readings of the 12v ADC. I tried to play with calibration values, but no luck with it. Eventually I have connected 0.1 µF capacitor to the ADC input, like described at "Minimizing Noise" article: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/pe... <https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/peripherals/adc.html> It might be worth considering this modification for the next hardware version.
вт, 17 авг. 2021 г. в 08:31, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>>: For the 4G modem options we need to go through FCC, CE, and ROHS certification. Minimising/eliminating the changes to the main board simplifies this (and brings down the exorbitant costs) but if there is anything urgent / necessary, now is the time to do it.
The goal here is to maintain 100% compatibility with existing OVMS main boards, to keep this is a simple and relatively cheap upgrade of the modem board.
So far, I have come up with this minimal list:
Main board v3.3: Improve soldering of micro USB port. Bigger solder pads, and more solder to secure it better.
Modem board v1.3: Add support for SIM7600 module.
Modem board v1.3: Fix support for DTR sleep/awake support.
Is there anything else required for this update?
Regards, Mark.
OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
I now have two prototypes of the 4G modem using SIM7600G R2 chip for OVMS v3.
One is for my own work, but willing to send the other free to a volunteer developer willing to spend time working with me to develop and test this new option. Obviously looking for someone who has spent some time on the OVMS code base, with a good history of contributions to the project and a willingness to work on improving the cellular modem driver.
Any volunteers? Please eMail me directly (mark@openvehicles.com <mailto:mark@openvehicles.com>).
Regards, Mark.
On 17 Aug 2021, at 1:30 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
For the 4G modem options we need to go through FCC, CE, and ROHS certification. Minimising/eliminating the changes to the main board simplifies this (and brings down the exorbitant costs) but if there is anything urgent / necessary, now is the time to do it.
The goal here is to maintain 100% compatibility with existing OVMS main boards, to keep this is a simple and relatively cheap upgrade of the modem board.
So far, I have come up with this minimal list:
Main board v3.3: Improve soldering of micro USB port. Bigger solder pads, and more solder to secure it better.
Modem board v1.3: Add support for SIM7600 module.
Modem board v1.3: Fix support for DTR sleep/awake support.
Is there anything else required for this update?
Regards, Mark.
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
On 8/29/21 11:03 PM, Mark Webb-Johnson wrote:
I now have two prototypes of the 4G modem using SIM7600G R2 chip for OVMS v3.
(Nice!)
One is for my own work, but willing to send the other free to a volunteer developer willing to spend time working with me to develop and test this new option. Obviously looking for someone who has spent some time on the OVMS code base, with a good history of contributions to the project and a willingness to work on improving the cellular modem driver.
Any volunteers? Please eMail me directly (mark@openvehicles.com <mailto:mark@openvehicles.com>).
Is my frankenstein v1.1 modem board with it's SIM7600A-H module close enough that I'll be able to help with this work?
- Modem board v1.3: Fix support for DTR sleep/awake support.
What would I need to do to make my v1.1 board have this? Are there any other v1.3 changes I would want?
I looked a little but I didn't find a source of bare SIM7600G-HR2 modules here in the US, only various breakout/usb/mini-pcie versions.
CraigSorry, Craig, I think I missed this eMail.
Is my frankenstein v1.1 modem board with it's SIM7600A-H module close enough that I'll be able to help with this work?
Yes. I am told that all the SIM7600 modules are the same apart from frequency coverage, so long as firmware version the same.
- Modem board v1.3: Fix support for DTR sleep/awake support. What would I need to do to make my v1.1 board have this? Are there any other v1.3 changes I would want?
Once we’ve resolved it on the new v3.3 board, we’ll publish the schematics and pcb layouts like before. But not yet ready and we are still working on it.
Regards, Mark.
On 31 Aug 2021, at 4:33 AM, Craig Leres <leres@xse.com> wrote:
On 8/29/21 11:03 PM, Mark Webb-Johnson wrote:
I now have two prototypes of the 4G modem using SIM7600G R2 chip for OVMS v3.
(Nice!)
One is for my own work, but willing to send the other free to a volunteer developer willing to spend time working with me to develop and test this new option. Obviously looking for someone who has spent some time on the OVMS code base, with a good history of contributions to the project and a willingness to work on improving the cellular modem driver. Any volunteers? Please eMail me directly (mark@openvehicles.com <mailto:mark@openvehicles.com>).
Is my frankenstein v1.1 modem board with it's SIM7600A-H module close enough that I'll be able to help with this work?
- Modem board v1.3: Fix support for DTR sleep/awake support.
What would I need to do to make my v1.1 board have this? Are there any other v1.3 changes I would want?
I looked a little but I didn't find a source of bare SIM7600G-HR2 modules here in the US, only various breakout/usb/mini-pcie versions.
Craig
I have 3.2.016-383-gfb7ccd6b (for-v3.3) on my dev unit and just checked in with it find that it does not have a ppp session after a couple of days of uptime. The gps seems to be working. What would be useful for me to do to debug this?
CraigOVMS# cell MODEM Status Model: SIM7600 Network Registration: RegisteredRoaming Provider: AT&T Hologram Signal: -87 dBm Mode: LTE,Online State: NetLoss Mux: Status up PPP: Not connected Last Error: User Interrupt GPS: Connected on channel: #1 I (264626012) cellular: State: Enter NetWait state I (264628012) gsm-ppp: StatusCallBack: User Interrupt I (264630012) cellular: State: Enter NetStart state I (264631052) cellular: PPP Connection is ready to start I (264632012) cellular: State: Enter NetMode state I (264632012) gsm-ppp: Initialising... I (264632102) cellular: PPP Connection disconnected I (264632102) cellular: PPP Connection disconnected W (264633012) cellular: Lost network connection (+PPP disconnect in NetMode) I (264633012) cellular: State: Enter NetLoss state I (264633012) gsm-ppp: Shutting down (hard)... I (264633012) gsm-ppp: PPP is shutdown I (264633012) netmanager: Set DNS#1 0.0.0.0 I (264633012) netmanager: Set DNS#2 0.0.0.0
Craig,
A log level debug output for the cellular systems would hopefully show what is going on.
Regards, Mark.
On 12 Sep 2021, at 10:15 AM, Craig Leres <leres@xse.com> wrote:
I have 3.2.016-383-gfb7ccd6b (for-v3.3) on my dev unit and just checked in with it find that it does not have a ppp session after a couple of days of uptime. The gps seems to be working. What would be useful for me to do to debug this?
CraigOVMS# cell MODEM Status Model: SIM7600 Network Registration: RegisteredRoaming Provider: AT&T Hologram Signal: -87 dBm Mode: LTE,Online State: NetLoss Mux: Status up PPP: Not connected Last Error: User Interrupt GPS: Connected on channel: #1 I (264626012) cellular: State: Enter NetWait state I (264628012) gsm-ppp: StatusCallBack: User Interrupt I (264630012) cellular: State: Enter NetStart state I (264631052) cellular: PPP Connection is ready to start I (264632012) cellular: State: Enter NetMode state I (264632012) gsm-ppp: Initialising... I (264632102) cellular: PPP Connection disconnected I (264632102) cellular: PPP Connection disconnected W (264633012) cellular: Lost network connection (+PPP disconnect in NetMode) I (264633012) cellular: State: Enter NetLoss state I (264633012) gsm-ppp: Shutting down (hard)... I (264633012) gsm-ppp: PPP is shutdown I (264633012) netmanager: Set DNS#1 0.0.0.0 I (264633012) netmanager: Set DNS#2 0.0.0.0
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
UART:
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: enabledI'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?
CraigCraig,
I can see some improvements:
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.
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?
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.
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 publish.
Regards, Mark.
On 12 Dec 2021, at 6:10 AM, Craig Leres <leres@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 UART: 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?
Craig
To add another data point here: my production module (running 3.3.001-8-gf98d941c)
OVMS# boot Last boot was 1093166 second(s) ago Time at boot: 2021-11-30 17:07:33 CET
OVMS# cell status deb MODEM Status Model: SIM5360 Network Registration: RegisteredHome Provider: congstar Signal: -85 dBm Mode: GSM,Online State: NetMode Ticker: 20096 User Data: 0 UART: 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 Status: enabled Time: enabled
Mark, maybe you can reproduce the effect by enabling the modem GPS.
Regards, Michael
Am 13.12.21 um 08:19 schrieb Mark Webb-Johnson:
Craig,
I can see some improvements:
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.
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?
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.
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 publish.
Regards, Mark.
On 12 Dec 2021, at 6:10 AM, Craig Leres <leres@xse.com <mailto:leres@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 UART: 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?
Craig
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
I don’t have GPS in any of my cars. I can try to enable on my bench.
Are we requesting GPS/GNSS updates from the modem too fast? I recollect that there is an AT command to set the frequency of updates.
@Craig do you have GPS/GNSS enabled on yours?
Regards, Mark.
On 13 Dec 2021, at 3:56 PM, Michael Balzer <dexter@expeedo.de> wrote:
Signed PGP part To add another data point here: my production module (running 3.3.001-8-gf98d941c)
OVMS# boot Last boot was 1093166 second(s) ago Time at boot: 2021-11-30 17:07:33 CET
OVMS# cell status deb MODEM Status Model: SIM5360 Network Registration: RegisteredHome Provider: congstar Signal: -85 dBm Mode: GSM,Online State: NetMode Ticker: 20096 User Data: 0 UART: 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 Status: enabled Time: enabled
Mark, maybe you can reproduce the effect by enabling the modem GPS.
Regards, Michael
Am 13.12.21 um 08:19 schrieb Mark Webb-Johnson:
Craig,
I can see some improvements:
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.
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?
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.
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 publish.
Regards, Mark.
On 12 Dec 2021, at 6:10 AM, Craig Leres <leres@xse.com <mailto:leres@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 UART: 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?
Craig-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
We subscribe to two NMEA sentences, which are sent once per second by the modem. I'm not aware of a command to control the update frequency, but once per second should be fine.
Example:
D (828673) gsm-nmea: Incoming GNS: $GNGNS,161731.0,5118.140633,N,00723.395401,E,AA,06,2.2,325.9,47.0,,*61 D (828673) gsm-nmea: Incoming RMC: $GPRMC,161731.0,A,5118.140633,N,00723.395401,E,0.0,,131221,,,A*43 D (829673) gsm-nmea: Incoming GNS: $GNGNS,161732.0,5118.140632,N,00723.395397,E,AA,06,2.2,325.9,47.0,,*6B D (829673) gsm-nmea: Incoming RMC: $GPRMC,161732.0,A,5118.140632,N,00723.395397,E,0.0,,131221,,,A*49 D (830673) gsm-nmea: Incoming GNS: $GNGNS,161733.0,5118.140629,N,00723.395389,E,AA,06,2.2,325.9,47.0,,*6F D (830673) gsm-nmea: Incoming RMC: $GPRMC,161733.0,A,5118.140629,N,00723.395389,E,0.0,,131221,,,A*4D
When just trying to fetch these examples from a fresh boot of my desk module, I also seem to have found a strange behaviour, the MUX driver lost the modem without any error being recorded:
I (42283) cellular: Set modem driver to 'SIM5360' I (42283) cellular: State: Enter PoweredOn state D (44323) cellular: mux-rx-line #0: +CPIN: READY D (44323) cellular: mux-rx-line #0: OPL UPDATING D (44323) cellular: mux-rx-line #0: PNN UPDATING D (44923) cellular: mux-rx-line #0: SMS DONE D (45503) cellular: mux-rx-line #0: CALL READY D (45503) cellular: mux-rx-line #0: PB DONE D (52273) cellular: tx-cmd: AT+CPIN?;+CREG=1;+CTZU=1;+CTZR=1;+CLIP=1;+CMGF=1;+CNMI=1,2,0,0,0;+CSDH=1;+CMEE=2;+CSQ;+AUTOCSQ=1,1;E0;S0=0 D (54273) cellular: tx-cmd: AT+CGMR;+ICCID D (58273) cellular: tx-cmd: AT+CMUXSRVPORT=3,1 D (58283) cellular: mux-rx-line #0: START D (58283) cellular: mux-rx-line #0: AT+CMUXSRVPORT=3,1 D (59273) cellular: tx-cmd: AT+CMUXSRVPORT=2,1 D (59283) cellular: mux-rx-line #0: AT+CMUXSRVPORT=2,1 D (60273) cellular: tx-cmd: AT+CMUXSRVPORT=1,1 D (60283) cellular: mux-rx-line #0: AT+CMUXSRVPORT=1,1 D (61273) cellular: tx-cmd: AT+CMUXSRVPORT=0,5 D (61283) cellular: mux-rx-line #0: AT+CMUXSRVPORT=0,5 D (61303) cellular: mux-rx-line #0: +CPIN: READY D (61303) cellular: mux-rx-line #0: OPL UPDATING D (61303) cellular: mux-rx-line #0: PNN UPDATING D (61553) ovms-duktape: Duktape: Compacting DukTape memory done in 100 ms D (61893) cellular: mux-rx-line #0: SMS DONE D (62273) cellular: tx-cmd: AT+CMUX=0 D (62283) cellular: mux-rx-line #0: AT+CMUX=0 I (62283) cellular: State: Enter MuxStart state D (62473) cellular: mux-rx-line #2: CALL READY D (62473) cellular: mux-rx-line #3: CALL READY D (62473) cellular: mux-rx-line #4: CALL READY D (62473) cellular: mux-rx-line #2: PB DONE D (62473) cellular: mux-rx-line #3: PB DONE D (62473) cellular: mux-rx-line #4: PB DONE D (63273) cellular: State transition MuxStart => NetWait I (63273) cellular: State: Enter NetWait state I (63273) gsm-nmea: Startup D (63273) cellular: mux-tx #4: AT+CGPSNMEA=66;+CGPS=1,1 D (63283) cellular: mux-rx-line #4: AT+CGPSNMEA=66;+CGPS=1,1 D (65013) gsm-nmea: Incoming GNS: $GNGNS,,,,,,NN,,,,,,*53 D (65013) gsm-nmea: Incoming RMC: $GPRMC,,V,,,,,,,,,,N*53 D (66013) gsm-nmea: Incoming GNS: $GNGNS,,,,,,NN,,,,,,*53 D (66013) gsm-nmea: Incoming RMC: $GPRMC,,V,,,,,,,,,,N*53 D (67013) gsm-nmea: Incoming GNS: $GNGNS,,,,,,NN,,,,,,*53 D (67013) gsm-nmea: Incoming RMC: $GPRMC,,V,,,,,,,,,,N*53 D (68003) gsm-nmea: Incoming GNS: $GNGNS,,,,,,NN,,,,,,*53 D (68013) gsm-nmea: Incoming RMC: $GPRMC,,V,,,,,,,,,,N*53 D (69003) gsm-nmea: Incoming GNS: $GNGNS,,,,,,NN,,,,,,*53 D (69013) gsm-nmea: Incoming RMC: $GPRMC,,V,,,,,,,,,,N*53 D (73273) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+COPS? D (83273) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+COPS? D (93273) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+COPS? D (103273) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+COPS? D (113273) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+COPS? D (121543) ovms-duktape: Duktape: Compacting DukTape memory done in 90 ms D (123273) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+COPS? D (133273) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+COPS? D (143273) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+COPS? OVMS# cell stat deb MODEM Status Model: SIM5360 Network Registration: Unknown Provider: Signal: 0 dBm Mode: State: NetWait Ticker: 80 User Data: 0 UART: FIFO overflows: 0 Buffer overflows: 0 Parity errors: 0 Frame errors: 0 Driver Buffer overflows: 0 Mux: Status up Open Channels: 4 Framing Errors: 0 RX frames: 23 TX frames: 14 Last RX frame: 75 sec(s) ago PPP: Not running GPS: Connected on channel: #1 Status: enabled Time: enabled D (153273) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+COPS? D (163273) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+COPS? D (173273) cellular: mux-tx #3: AT+CREG?;+CCLK?;+CSQ;+COPS?
Regards, Michael
Am 13.12.21 um 09:09 schrieb Mark Webb-Johnson:
I don’t have GPS in any of my cars. I can try to enable on my bench.
Are we requesting GPS/GNSS updates from the modem too fast? I recollect that there is an AT command to set the frequency of updates.
@Craig do you have GPS/GNSS enabled on yours?
Regards, Mark.
On 13 Dec 2021, at 3:56 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Signed PGP part To add another data point here: my production module (running 3.3.001-8-gf98d941c)
OVMS# boot Last boot was 1093166 second(s) ago Time at boot: 2021-11-30 17:07:33 CET
OVMS# cell status deb MODEM Status Model: SIM5360 Network Registration: RegisteredHome Provider: congstar Signal: -85 dBm Mode: GSM,Online State: NetMode Ticker: 20096 User Data: 0 UART: 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 Status: enabled Time: enabled
Mark, maybe you can reproduce the effect by enabling the modem GPS.
Regards, Michael
Am 13.12.21 um 08:19 schrieb Mark Webb-Johnson:
Craig,
I can see some improvements:
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.
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?
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.
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 publish.
Regards, Mark.
On 12 Dec 2021, at 6:10 AM, Craig Leres <leres@xse.com <mailto:leres@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 UART: 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?
Craig
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
On 12/12/21 23:19, Mark Webb-Johnson wrote:
I can see some improvements:
- 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.
I'm not sure if I mentioned it before but when ppp tanks, gps continues to work.
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?
Is the hw overflow in a uart in the esp32? I found this thread about uart overflows:
https://esp32.com/viewtopic.php?t=534Sounds like the hardware has 128 bytes of buffer.
On 12/13/21 08:28, Michael Balzer wrote:
We subscribe to two NMEA sentences, which are sent once per second by the modem.
Looks like it's these two:
https://www.trimble.com/oem_receiverhelp/v4.44/en/NMEA-0183messages_GNS.html
https://www.trimble.com/oem_receiverhelp/v4.44/en/NMEA-0183messages_RMC.html
Since both have latitude, longitude, and time I'm guessing you want both because GNS includes a finely grained mode indicator and number of satellites being tracked while RMC includes the track angle.
- 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.
I remember seeing hw flow control being mentioned for the new hardware but I see now you shot that down:
On 8/17/21 00:55, Mark Webb-Johnson wrote:
- Any chance to fix the missing HW flow control on the modem UART connection?
I don’t think we have enough GPIOs. Perhaps later when/if ESP32 S3 becomes suitable?
And I'm guessing there is no change for this either?
On 8/16/21 22:30, Mark Webb-Johnson wrote:
Modem board v1.3: Fix support for DTR sleep/awake support.
- 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 publish.
(I see you also committed versions, thanks!)
The only difference I could find is a pullup resistor on "FLIGHTMODE" which I guess allows AT command control over the flightmode feature? But I didn't find any code to enable flightmode. So probably something I don't need?
Aside from the v3 esp32, what differences does the V3.3 main board have compared to a V3.2 board?
On 12/13/21 00:09, Mark Webb-Johnson wrote:
@Craig do you have GPS/GNSS enabled on yours?
(Yes and) a week ago I converted my spare modem board with the other sim7600 module I had (giving me two total) and I put it in my Cadillac. It worked great until a few miles from work and then it wedged. I tried plugging in a laptop to confirm ppp had tanked but the solder on the usb pins had cracked again so I had to settle for cycling power.
I put the 5360 back in that car and since then I've rarely seen the dev/bench unit lose ppp. I'm wondering now if it's because I've turned on a bunch of gsm related logging and that's changed the timing somehow?
Going back the 128 byte buffer: aside from GNSS, what other messages does the modem send to the ovms module? I'm thinking most of the data flows from ovms out (e.g. V2 and V3 updates). Perhaps the timing of messages is such that it's rare but possible to have 3 or 4 arrive at the same time and fill up the buffer?
Another thing I wondered about was does the ppp startup process get short circuited because the modem (unhelpfully) tells us that ppp is disconnected while we're trying to start ppp and when we see that we tear down ppp?
OVMS# D (266645953) cellular: Netstart AT+CGDCONT=1,"IP","hologram";+CGDATA="PPP",1 D (266645993) cellular: mux-rx-line #2: CONNECT 115200 I (266645993) cellular: PPP Connection is ready to start OVMS# D (266646953) cellular: State transition NetStart => NetMode I (266646953) cellular: State: Enter NetMode state V (266646953) cellular: Starting PPP I (266646953) gsm-ppp: Initialising... D (266647033) cellular: mux-rx-line #3: NO CARRIER D (266647033) cellular: mux-rx-line #4: NO CARRIER D (266647043) cellular: mux-rx-line #3: +PPPD: DISCONNECTED I (266647043) cellular: PPP Connection disconnected D (266647043) cellular: mux-rx-line #4: +PPPD: DISCONNECTED I (266647043) cellular: PPP Connection disconnected OVMS# W (266647953) cellular: Lost network connection (+PPP disconnect in NetMode) D (266647953) cellular: State transition NetMode => NetLoss I (266647953) cellular: State: Enter NetLoss state D (266647953) cellular: mux-tx #3: AT+CGATT=0 V (266647953) cellular: Stopping PPP I (266647953) gsm-ppp: Shutting down (hard)... I (266647953) gsm-ppp: PPP is shutdown I (266647953) netmanager: Set DNS#1 0.0.0.0 I (266647963) netmanager: Set DNS#2 0.0.0.0
This is probably enough rambling and speculation for now.
CraigCraig,
some earlier discussions on the fifo issue with some answers:
- https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/274
- http://lists.openvehicles.com/pipermail/ovmsdev/2019-October/013749.html
Regards, Michael
Am 13.12.21 um 22:28 schrieb Craig Leres:
On 12/12/21 23:19, Mark Webb-Johnson wrote:
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.
I'm not sure if I mentioned it before but when ppp tanks, gps continues to work.
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?
Is the hw overflow in a uart in the esp32? I found this thread about uart overflows:
https://esp32.com/viewtopic.php?t=534
Sounds like the hardware has 128 bytes of buffer.
On 12/13/21 08:28, Michael Balzer wrote:
We subscribe to two NMEA sentences, which are sent once per second by the modem.
Looks like it's these two:
https://www.trimble.com/oem_receiverhelp/v4.44/en/NMEA-0183messages_GNS.html
https://www.trimble.com/oem_receiverhelp/v4.44/en/NMEA-0183messages_RMC.html
Since both have latitude, longitude, and time I'm guessing you want both because GNS includes a finely grained mode indicator and number of satellites being tracked while RMC includes the track angle.
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.
I remember seeing hw flow control being mentioned for the new hardware but I see now you shot that down:
On 8/17/21 00:55, Mark Webb-Johnson wrote:
- Any chance to fix the missing HW flow control on the modem UART connection?
I don’t think we have enough GPIOs. Perhaps later when/if ESP32 S3 becomes suitable?
And I'm guessing there is no change for this either?
On 8/16/21 22:30, Mark Webb-Johnson wrote:
Modem board v1.3: Fix support for DTR sleep/awake support.
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 publish.
(I see you also committed versions, thanks!)
The only difference I could find is a pullup resistor on "FLIGHTMODE" which I guess allows AT command control over the flightmode feature? But I didn't find any code to enable flightmode. So probably something I don't need?
Aside from the v3 esp32, what differences does the V3.3 main board have compared to a V3.2 board?
On 12/13/21 00:09, Mark Webb-Johnson wrote:
@Craig do you have GPS/GNSS enabled on yours?
(Yes and) a week ago I converted my spare modem board with the other sim7600 module I had (giving me two total) and I put it in my Cadillac. It worked great until a few miles from work and then it wedged. I tried plugging in a laptop to confirm ppp had tanked but the solder on the usb pins had cracked again so I had to settle for cycling power.
I put the 5360 back in that car and since then I've rarely seen the dev/bench unit lose ppp. I'm wondering now if it's because I've turned on a bunch of gsm related logging and that's changed the timing somehow?
Going back the 128 byte buffer: aside from GNSS, what other messages does the modem send to the ovms module? I'm thinking most of the data flows from ovms out (e.g. V2 and V3 updates). Perhaps the timing of messages is such that it's rare but possible to have 3 or 4 arrive at the same time and fill up the buffer?
Another thing I wondered about was does the ppp startup process get short circuited because the modem (unhelpfully) tells us that ppp is disconnected while we're trying to start ppp and when we see that we tear down ppp?
OVMS# D (266645953) cellular: Netstart AT+CGDCONT=1,"IP","hologram";+CGDATA="PPP",1 D (266645993) cellular: mux-rx-line #2: CONNECT 115200 I (266645993) cellular: PPP Connection is ready to start OVMS# D (266646953) cellular: State transition NetStart => NetMode I (266646953) cellular: State: Enter NetMode state V (266646953) cellular: Starting PPP I (266646953) gsm-ppp: Initialising... D (266647033) cellular: mux-rx-line #3: NO CARRIER D (266647033) cellular: mux-rx-line #4: NO CARRIER D (266647043) cellular: mux-rx-line #3: +PPPD: DISCONNECTED I (266647043) cellular: PPP Connection disconnected D (266647043) cellular: mux-rx-line #4: +PPPD: DISCONNECTED I (266647043) cellular: PPP Connection disconnected OVMS# W (266647953) cellular: Lost network connection (+PPP disconnect in NetMode) D (266647953) cellular: State transition NetMode => NetLoss I (266647953) cellular: State: Enter NetLoss state D (266647953) cellular: mux-tx #3: AT+CGATT=0 V (266647953) cellular: Stopping PPP I (266647953) gsm-ppp: Shutting down (hard)... I (266647953) gsm-ppp: PPP is shutdown I (266647953) netmanager: Set DNS#1 0.0.0.0 I (266647963) netmanager: Set DNS#2 0.0.0.0
This is probably enough rambling and speculation for now.
Craig
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
On 12/13/21 13:48, Michael Balzer wrote:
some earlier discussions on the fifo issue with some answers:
Helpful, thanks!
One thing I don't think I've mentioned before is that my dev ovms unit has an upgrade cp2102. I figured out later that this broke my ability to use the microsd slot but maybe it explains why I see the fifo overrun less frequently?
CraigI've seen my dev modem go into "user interrupt" several times without accompanying uart fifo overflows. So now I doubt there is any connection between these two issues. I've been thinking that a strategy for debugging the "User Interrupt" issue would be to wait for the modem to get stuck and then send commands. But I guess ppp is implemented in esp-idf? (Maybe I should compare with a recent esp-idf to see if there are any interesting changes?) Still, I wanted to be able to send commands to the modem without fighting with the modem driver. When I looked I found there was already a Development modem state but it isn't registered as a command and I didn't see how it could be enabled. Is this a reasonable thing for me to create a PR to add it? @@ -1679,7 +1693,7 @@ CellularModemInit::CellularModemInit() cmd_status->RegisterCommand("debug","Show extended CELLULAR MODEM status",cellular_status, "", 0, 0, false); OvmsCommand* cmd_setstate = cmd_cellular->RegisterCommand("setstate","CELLULAR MODEM state change framework"); - for (int x = modem::CheckPowerOff; x<=modem::PowerOffOn; x++) + for (int x = modem::CheckPowerOff; x<=modem::Development; x++) { cmd_setstate->RegisterCommand(ModemState1Name((modem::modem_state1_t)x),"Force CELLULAR MODEM state change",modem_setstate); } I tried that but then it's very difficult to do anything interactive with the modem when in Development state due to the many printouts that get enabled, e.g: void modem::tx(uint8_t* data, size_t size) { if (!m_task) return; // Quick exit if not task (we are stopped) if (m_state1 == Development) { DevelopmentHexDump("tx", (const char*)data, size); } uart_write_bytes(m_uartnum, (const char*)data, size); } (I get flooded with the gnss/nmea messages.) What's a good way to add the ability to disable these? A new "Development2" state? Maybe tie these messages to a new "cellular-trace" tag? Craig
The ‘devel’ state was intended for debugging and development work on the modem. It puts the cellular driver code into a state where it doesn’t send commands any more, and displays transmit/receive traffic as dumps. You can put it into this mode with ‘power cellular devel’ (usually after the modem MUX is up). I’m still working trying to find out why the modem driver gets into this weird state. When I see it, if I ‘power cellular off’, wait for power down, then ‘power cellular on’, the connection is re-established. Similarly, resetting the module re-establishes the connection. Given that we already power cycle the modem if the connection can’t be established for a while, the problem is clearly in the driver code. Most likely the UART. Early on in the 3.3 project I tried completely clearing that (including PPP) but ran into bugs in the esp32 hardware/IDF corrupting memory. I will try again. Regards, Mark.
On 2 Jan 2022, at 5:55 AM, Craig Leres <leres@xse.com> wrote:
I've seen my dev modem go into "user interrupt" several times without accompanying uart fifo overflows. So now I doubt there is any connection between these two issues.
I've been thinking that a strategy for debugging the "User Interrupt" issue would be to wait for the modem to get stuck and then send commands. But I guess ppp is implemented in esp-idf? (Maybe I should compare with a recent esp-idf to see if there are any interesting changes?) Still, I wanted to be able to send commands to the modem without fighting with the modem driver. When I looked I found there was already a Development modem state but it isn't registered as a command and I didn't see how it could be enabled. Is this a reasonable thing for me to create a PR to add it?
@@ -1679,7 +1693,7 @@ CellularModemInit::CellularModemInit() cmd_status->RegisterCommand("debug","Show extended CELLULAR MODEM status",cellular_status, "", 0, 0, false);
OvmsCommand* cmd_setstate = cmd_cellular->RegisterCommand("setstate","CELLULAR MODEM state change framework"); - for (int x = modem::CheckPowerOff; x<=modem::PowerOffOn; x++) + for (int x = modem::CheckPowerOff; x<=modem::Development; x++) { cmd_setstate->RegisterCommand(ModemState1Name((modem::modem_state1_t)x),"Force CELLULAR MODEM state change",modem_setstate); }
I tried that but then it's very difficult to do anything interactive with the modem when in Development state due to the many printouts that get enabled, e.g:
void modem::tx(uint8_t* data, size_t size) { if (!m_task) return; // Quick exit if not task (we are stopped)
if (m_state1 == Development) { DevelopmentHexDump("tx", (const char*)data, size); }
uart_write_bytes(m_uartnum, (const char*)data, size); }
(I get flooded with the gnss/nmea messages.) What's a good way to add the ability to disable these? A new "Development2" state? Maybe tie these messages to a new "cellular-trace" tag?
Craig _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
I'd like to congratulate Mark and crew on the v3.3 hardware; I've been running with one new v3.3 ovms module and two new sim7600G modems for a few weeks without issue. While I still see the new modems connecting to 3G at times, it's really nice to have 4G capability well in advice of the retirement of 3G. (The updated v3 esp32 is also nice...)
Given that my frankenstein modules still go into "user interrupt" after so many hours of uptime, I think the best explanation is that it is due to differences in their sim7600A-H firmware. I'd offer to ship Mark one of mine for debugging if that would be at all useful given he is not located in north america. (And if there is someone in the US that would like to take a run at solving sim7600A issues, contact me offline.)
CraigI've encountered an issue with the final batch module that didn't occur with the hand soldered test version: I wasn't able to boot from USB power. All my other modules work perfectly from my powered USB hub, this doesn't.
It only has issues with a cold start: if I use a 12V supply when switching it on, I can remove the 12V supply after boot and also do reboots while only supplying USB power. The next cold boot from USB will fail again.
The module keeps rebooting with a "brownout detector was triggered" message right after adding the SPIRAM pool:
ets Jul 29 2019 12:21:46
rst:0xc (SW_CPU_RESET),boot:0x1b (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0018,len:4 load:0x3fff001c,len:5328 ho 0 tail 12 room 4 load:0x40078000,len:11332 load:0x40080400,len:6204 entry 0x400806cc I (1053) psram: This chip is ESP32-D0WD I (1054) spiram: Found 64MBit SPI RAM device I (1054) spiram: SPI RAM mode: flash 40m sram 40m I (1057) spiram: PSRAM initialized, cache is in low/high (2-core) mode. I (1064) cpu_start: Pro cpu up. I (1068) cpu_start: Application information: I (1073) cpu_start: Project name: ovms3 I (1078) cpu_start: App version: 3.3.001-285-g601f2a70 I (1084) cpu_start: Compile time: Feb 19 2022 07:59:04 I (1090) cpu_start: ELF file SHA256: 09c85890b31e6080... I (1096) cpu_start: ESP-IDF: v3.3.4-848-g1ff5e24b1b I (1103) cpu_start: Starting app cpu, entry point is 0x400818d4 I (1094) cpu_start: App cpu up. I (1981) spiram: SPI SRAM memory test OK I (1981) heap_init: Initializing. RAM available for dynamic allocation: I (1981) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM I (1987) heap_init: At 3FFBF770 len 00020890 (130 KiB): DRAM I (1994) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM I (2000) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM I (2007) heap_init: At 4009CCFC len 00003304 (12 KiB): IRAM I (2013) cpu_start: Pro cpu start user code I (2018) spiram: Adding pool of 4096K of external SPI memory to heap allocator
*Brownout detector was triggered*
ets Jul 29 2019 12:21:46
rst:0xc (SW_CPU_RESET),boot:0x1b (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0018,len:4 load:0x3fff001c,len:5328 ho 0 tail 12 room 4 load:0x40078000,len:11332 load:0x40080400,len:6204 entry 0x400806cc I (1053) psram: This chip is ESP32-D0WD …
Does the new mainboard draw a higher current? Or is the modem possibly configured differently from the test module causing an early high current consumption?
Regards, Michael
Am 22.02.22 um 19:35 schrieb Craig Leres:
I'd like to congratulate Mark and crew on the v3.3 hardware; I've been running with one new v3.3 ovms module and two new sim7600G modems for a few weeks without issue. While I still see the new modems connecting to 3G at times, it's really nice to have 4G capability well in advice of the retirement of 3G. (The updated v3 esp32 is also nice...)
Given that my frankenstein modules still go into "user interrupt" after so many hours of uptime, I think the best explanation is that it is due to differences in their sim7600A-H firmware. I'd offer to ship Mark one of mine for debugging if that would be at all useful given he is not located in north america. (And if there is someone in the US that would like to take a run at solving sim7600A issues, contact me offline.)
Craig
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
On 2/22/22 12:47, Michael Balzer wrote:
The module keeps rebooting with a "brownout detector was triggered" message right after adding the SPIRAM pool:
I see you can configure the brownout detection voltage:
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/kc...
It's not clear to me what the default value is but the feature is enabled by default.
I've had a *lot* of fun messing with brownout detection with arduino projects. It can be particular challenging to get it to play nice when running atmega's at 3.3V.
CraigA progress update.
I merged in master -> for-v3.3 branch. It was kind of messy, due to some conflicting changes made to metrics, command, and script/duktape, but I think I got it correct. We will need to carefully review this before release of v3.3.
The SIM7600G R2 seems to work well. A few changes from SIM5360 in the AT commands, but it seems to basically work:
OVMS# power cellular on Power mode of cellular is now on I (8736313) cellular: Set modem driver to 'auto' I (8736313) cellular: State: Enter PoweringOn state I (8736323) cellular-modem-auto: Power Cycle 2000ms I (8753853) cellular: State: Enter Identify state I (8754823) cellular: Identified cellular modem: SIM7600/Experimental support for SIMCOM SIM7600 I (8754823) cellular: Set modem driver to ‘SIM7600' … I (8764843) cellular: Signal Quality is: 21 (-71 dBm) I (8774823) cellular: State: Enter MuxStart state I (8774823) gsm-mux: Start MUX I (8774833) gsm-mux: Channel #0 is open I (8774843) gsm-mux: Channel #1 is open I (8774853) gsm-mux: Channel #2 is open I (8774863) gsm-mux: Channel #3 is open I (8774873) gsm-mux: Channel #4 is open I (8775813) cellular: State: Enter NetWait state I (8775813) gsm-nmea: Startup I (8785843) cellular: Network Registration status: RegisteredRoaming I (8785843) cellular: Network Provider is: CSL Hologram I (8786803) cellular: Signal Quality is: 31 (-51 dBm) … I (8788813) gsm-ppp: Initialising... I (8788953) gsm-ppp: StatusCallBack: None I (8788953) gsm-ppp: status_cb: Connected I (8788953) gsm-ppp: our_ipaddr = 10.170.204.16 … I (8817863) location: UpdateParkPosition: vehicle is parking @(redacted) gpslock=1 satcount=5 hdop=3.0 invalid=0 …
OVMS# cellular status MODEM Status Model: SIM7600 Network Registration: RegisteredRoaming Provider: CSL Hologram Signal: -51 dBm Mode: LTE,Online State: NetMode Mux: Status up PPP: Connected on channel: #2 GPS: Connected on channel: #1
OVMS# metric list mdm m.net.mdm.iccid 8944500(redacted) m.net.mdm.mode LTE,Online m.net.mdm.model LE20B03SIM7600M21-A m.net.mdm.netreg RegisteredRoaming m.net.mdm.network CSL Hologram m.net.mdm.sq -51dBm
I’m now finalising the hardware changes, and then it can go to certification (which takes at least two months, probably).
Regards, Mark.
On 30 Aug 2021, at 2:03 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
I now have two prototypes of the 4G modem using SIM7600G R2 chip for OVMS v3.
One is for my own work, but willing to send the other free to a volunteer developer willing to spend time working with me to develop and test this new option. Obviously looking for someone who has spent some time on the OVMS code base, with a good history of contributions to the project and a willingness to work on improving the cellular modem driver.
Any volunteers? Please eMail me directly (mark@openvehicles.com <mailto:mark@openvehicles.com>).
Regards, Mark.
<IMG_9926.png>
On 17 Aug 2021, at 1:30 PM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
For the 4G modem options we need to go through FCC, CE, and ROHS certification. Minimising/eliminating the changes to the main board simplifies this (and brings down the exorbitant costs) but if there is anything urgent / necessary, now is the time to do it.
The goal here is to maintain 100% compatibility with existing OVMS main boards, to keep this is a simple and relatively cheap upgrade of the modem board.
So far, I have come up with this minimal list:
Main board v3.3: Improve soldering of micro USB port. Bigger solder pads, and more solder to secure it better.
Modem board v1.3: Add support for SIM7600 module.
Modem board v1.3: Fix support for DTR sleep/awake support.
Is there anything else required for this update?
Regards, Mark.
OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
On 8/29/21 11:03 PM, Mark Webb-Johnson wrote:
I now have two prototypes of the 4G modem using SIM7600G R2 chip for OVMS v3.
I was comparing the v1.1 and v1.2 modem schematics to see what the differences are between my sim7600 converted board (v1.1) and the current production version. It looks like some inductors and related parts were added to the power supply (and I sort of remember you describing this back when the v3.2 ovms board came out).
I noticed the pdf files for the v1.2 modems are misnamed in the source tree:
ice 521 % find . -name '*.pdf' | fgrep -i modem
./hardware/v3.1/Modem_PCB_v1.1_20180305.pdf
./hardware/v3.1/Modem_SCH_v1.1_20180305.pdf
./hardware/v3.2/Modem_PCB_v3.2_20190610.pdf
./hardware/v3.2/Modem_SCH_v3.2_20190610.pdfShouldn't the ones in the v3.2 directory be named *v1.2_20190610.pdf?
Aside from the R8/R9 to R6/R6 and u.fl component swap, are there other differences between the v1.2 and v1.3 modem boards? (Is it too soon to add the v3.3 and v1.3 pdfs to the source tree?)
On 8/17/21 12:31 AM, Michael Balzer wrote:
- Any chance to fix the missing HW flow control on the modem UART connection?
(Is this the source of the "W (541151) cellular: UART hw fifo overflow" I see periodically?)
CraigThe board numbering we have used is:
v3.0 (modem 1.0): initial prototype development version, never wen’t to full production v3.1 (modem 1.1): first production version v3.2 (modem 1.2): production version with CE, FCC and ROHS certification. Changes from v3.2 were to add extra components to pass EMC and other such tests (no change to core functions).
The upcoming v3.3 will have some minor hardware fixes and include a v3.3 modem board supporting SIM7600. Going forward we will try to keep the modem and main board revision numbers the same. The old v1.1/v1.2 modem boards can also be used with this v3.3 main board, and the new v3.3 modem board will be able to be used with old v3.1 and v3.2 main boards.
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).
- Any chance to fix the missing HW flow control on the modem UART connection?
(Is this the source of the "W (541151) cellular: UART hw fifo overflow" I see periodically?)
Probably.
Regards, Mark.
On 7 Sep 2021, at 7:13 AM, Craig Leres <leres@xse.com> wrote:
On 8/29/21 11:03 PM, Mark Webb-Johnson wrote:
I now have two prototypes of the 4G modem using SIM7600G R2 chip for OVMS v3.
I was comparing the v1.1 and v1.2 modem schematics to see what the differences are between my sim7600 converted board (v1.1) and the current production version. It looks like some inductors and related parts were added to the power supply (and I sort of remember you describing this back when the v3.2 ovms board came out).
I noticed the pdf files for the v1.2 modems are misnamed in the source tree:
ice 521 % find . -name '*.pdf' | fgrep -i modem ./hardware/v3.1/Modem_PCB_v1.1_20180305.pdf ./hardware/v3.1/Modem_SCH_v1.1_20180305.pdf ./hardware/v3.2/Modem_PCB_v3.2_20190610.pdf ./hardware/v3.2/Modem_SCH_v3.2_20190610.pdf
Shouldn't the ones in the v3.2 directory be named *v1.2_20190610.pdf?
Aside from the R8/R9 to R6/R6 and u.fl component swap, are there other differences between the v1.2 and v1.3 modem boards? (Is it too soon to add the v3.3 and v1.3 pdfs to the source tree?)
On 8/17/21 12:31 AM, Michael Balzer wrote:
- Any chance to fix the missing HW flow control on the modem UART connection?
(Is this the source of the "W (541151) cellular: UART hw fifo overflow" I see periodically?)
Craig
Craig,
Am 07.09.21 um 01:13 schrieb Craig Leres:
On 8/17/21 12:31 AM, Michael Balzer wrote:
- Any chance to fix the missing HW flow control on the modem UART connection?
(Is this the source of the "W (541151) cellular: UART hw fifo overflow" I see periodically?)
Yes, and you'll often see "gsm-mux: Frame error: EOF mismatch" log lines in combination with these.
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 Time: enabled
See also:
- https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/274
- https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/350
- http://lists.openvehicles.com/pipermail/ovmsdev/2019-October/013744.html
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Progress update…
I’ve completed the basic support for plugin modem drivers and SIM7600 in the for-v3.3 branch, and it seems stable on my bench and car (although I never saw many problems before with this). I would still appreciate it if others could test and feedback any crashes they get. You can get the update OTA from api.openvehicles.com <http://api.openvehicles.com/> by setting tag ‘pre’.
We’ve also completed the testing of the hardware. The DTR low-power control option seems to be working well (but will require firmware support later). The ‘final’ list of hardware changes are as follows:
Main Board: Silkscreen label “OVMS V3.3” (with date of production batch) Change to improved internal antenna cables for GSM and GPS Strengthen soldering on micro USB connector Strengthen soldering on power supply capacitors WROVER module to use revision 3 ESP32 Add 0.1uF capacitor to 12v measuring voltage divider ADC input (https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/pe... <https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/peripherals/adc.html#minimizing-noise>)
Modem Board: Silkscreen label “OVMS MDM V3.3” (with date of production batch) Add support for SIM7600 module Fixed DTR support Improve/check voltage regulator and capacitor protection Reduce brightness of blue LED by at least 50% Airplane mode pin fix (working ok now, but safer to pull up/down properly) Confirm PWRKEY circuit tuning
Enclosure Product label - just one label with CE and FCC certification for global use
We are now producing a few final samples of the above to go to the certification labs for CE, FCC, and ROHS testing later this month. We hope that certification will take 6 to 8 weeks and be complete around the end of November. Once that is done, we should be able to go to full production in time for Christmas. Pricing will be confirmed early December, but likely more expensive than v3.2 due to the extra cost for SIM7600G and certification fees.
Stock of existing SIM5360 modules are as follows:
EU kits; in stock at open energy monitor (but selling out fast and likely to be unavailable soon). US kits; in stock at Medlock, Fasttech, and Open Vehicles (HK).
Regards, Mark
On 30 Aug 2021, at 2:03 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
I now have two prototypes of the 4G modem using SIM7600G R2 chip for OVMS v3.
One is for my own work, but willing to send the other free to a volunteer developer willing to spend time working with me to develop and test this new option. Obviously looking for someone who has spent some time on the OVMS code base, with a good history of contributions to the project and a willingness to work on improving the cellular modem driver.
Any volunteers? Please eMail me directly (mark@openvehicles.com <mailto:mark@openvehicles.com>).
Regards, Mark.
<IMG_9926.png>
On 17 Aug 2021, at 1:30 PM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
For the 4G modem options we need to go through FCC, CE, and ROHS certification. Minimising/eliminating the changes to the main board simplifies this (and brings down the exorbitant costs) but if there is anything urgent / necessary, now is the time to do it.
The goal here is to maintain 100% compatibility with existing OVMS main boards, to keep this is a simple and relatively cheap upgrade of the modem board.
So far, I have come up with this minimal list:
Main board v3.3: Improve soldering of micro USB port. Bigger solder pads, and more solder to secure it better.
Modem board v1.3: Add support for SIM7600 module.
Modem board v1.3: Fix support for DTR sleep/awake support.
Is there anything else required for this update?
Regards, Mark.
OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
First ‘final’ v3.3 sample received (the one that also went to the certification lab):
rst:0xc (SW_CPU_RESET),boot:0x1b (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0018,len:4 load:0x3fff001c,len:4796 load:0x40078000,len:0 load:0x40078000,len:14896 entry 0x40078d74 I (1062) psram: This chip is ESP32-D0WD I (1062) spiram: Found 64MBit SPI RAM device I (1062) spiram: SPI RAM mode: flash 40m sram 40m I (1065) spiram: PSRAM initialized, cache is in low/high (2-core) mode. I (1072) cpu_start: Pro cpu up. I (1076) cpu_start: Application information: I (1081) cpu_start: Project name: ovms3 I (1086) cpu_start: App version: 3.2.016-393-g07db2f8d I (1092) cpu_start: Compile time: Sep 16 2021 21:09:48 I (1099) cpu_start: ELF file SHA256: 8aa1db50ae1ea15d... I (1105) cpu_start: ESP-IDF: v3.3.4-848-g1ff5e24b1 I (1111) cpu_start: Starting app cpu, entry point is 0x40081720 I (1103) cpu_start: App cpu up. I (1989) spiram: SPI SRAM memory test OK I (1989) heap_init: Initializing. RAM available for dynamic allocation: I (1989) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM I (1996) heap_init: At 3FFBE250 len 00021DB0 (135 KiB): DRAM I (2002) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM I (2008) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM I (2015) heap_init: At 4009D5A4 len 00002A5C (10 KiB): IRAM I (2021) cpu_start: Pro cpu start user code I (2026) spiram: Adding pool of 4096K of external SPI memory to heap allocator ... Welcome to the Open Vehicle Monitoring System (OVMS) - Async Console Firmware: 3.2.016-393-g07db2f8d/factory/main Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/3 ... OVMS# module memory Free 8-bit 103580/273840, 32-bit 6440/10796, SPIRAM 3460832/4194252 ... Module Version: 3.2.016-393-g07db2f8d/factory/main (build idf v3.3.4-848-g1ff5e24b1 Sep 16 2021 21:12:48) Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/3
$ esptool.py --port /dev/tty.usbserial-0001 --baud 115200 chip_id esptool.py v2.8 Serial port /dev/tty.usbserial-0001 Connecting.... Detecting chip type... ESP32 Chip is ESP32D0WDQ5 (revision 3) Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None Crystal is 40MHz
Michael should be very happy with that @ESP32D0WDQ5 (revision 3).
I’m working through the other tests now, but so far so good.
Regards, Mar.
On 14 Sep 2021, at 3:01 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Progress update…
I’ve completed the basic support for plugin modem drivers and SIM7600 in the for-v3.3 branch, and it seems stable on my bench and car (although I never saw many problems before with this). I would still appreciate it if others could test and feedback any crashes they get. You can get the update OTA from api.openvehicles.com <http://api.openvehicles.com/> by setting tag ‘pre’.
We’ve also completed the testing of the hardware. The DTR low-power control option seems to be working well (but will require firmware support later). The ‘final’ list of hardware changes are as follows:
Main Board: Silkscreen label “OVMS V3.3” (with date of production batch) Change to improved internal antenna cables for GSM and GPS Strengthen soldering on micro USB connector Strengthen soldering on power supply capacitors WROVER module to use revision 3 ESP32 Add 0.1uF capacitor to 12v measuring voltage divider ADC input (https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/pe... <https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/peripherals/adc.html#minimizing-noise>)
Modem Board: Silkscreen label “OVMS MDM V3.3” (with date of production batch) Add support for SIM7600 module Fixed DTR support Improve/check voltage regulator and capacitor protection Reduce brightness of blue LED by at least 50% Airplane mode pin fix (working ok now, but safer to pull up/down properly) Confirm PWRKEY circuit tuning
Enclosure Product label - just one label with CE and FCC certification for global use
We are now producing a few final samples of the above to go to the certification labs for CE, FCC, and ROHS testing later this month. We hope that certification will take 6 to 8 weeks and be complete around the end of November. Once that is done, we should be able to go to full production in time for Christmas. Pricing will be confirmed early December, but likely more expensive than v3.2 due to the extra cost for SIM7600G and certification fees.
Stock of existing SIM5360 modules are as follows:
EU kits; in stock at open energy monitor (but selling out fast and likely to be unavailable soon). US kits; in stock at Medlock, Fasttech, and Open Vehicles (HK).
Regards, Mark
On 30 Aug 2021, at 2:03 PM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
I now have two prototypes of the 4G modem using SIM7600G R2 chip for OVMS v3.
One is for my own work, but willing to send the other free to a volunteer developer willing to spend time working with me to develop and test this new option. Obviously looking for someone who has spent some time on the OVMS code base, with a good history of contributions to the project and a willingness to work on improving the cellular modem driver.
Any volunteers? Please eMail me directly (mark@openvehicles.com <mailto:mark@openvehicles.com>).
Regards, Mark.
<IMG_9926.png>
On 17 Aug 2021, at 1:30 PM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
For the 4G modem options we need to go through FCC, CE, and ROHS certification. Minimising/eliminating the changes to the main board simplifies this (and brings down the exorbitant costs) but if there is anything urgent / necessary, now is the time to do it.
The goal here is to maintain 100% compatibility with existing OVMS main boards, to keep this is a simple and relatively cheap upgrade of the modem board.
So far, I have come up with this minimal list:
Main board v3.3: Improve soldering of micro USB port. Bigger solder pads, and more solder to secure it better.
Modem board v1.3: Add support for SIM7600 module.
Modem board v1.3: Fix support for DTR sleep/awake support.
Is there anything else required for this update?
Regards, Mark.
OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Michael should be very happy with that @ESP32D0WDQ5 (revision 3).
I am indeed :-)
Regards, Michael
Am 12.10.21 um 13:38 schrieb Mark Webb-Johnson:
First ‘final’ v3.3 sample received (the one that also went to the certification lab):
rst:0xc (SW_CPU_RESET),boot:0x1b (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0018,len:4 load:0x3fff001c,len:4796 load:0x40078000,len:0 load:0x40078000,len:14896 entry 0x40078d74 I (1062) psram: This chip is ESP32-D0WD I (1062) spiram: Found 64MBit SPI RAM device I (1062) spiram: SPI RAM mode: flash 40m sram 40m I (1065) spiram: PSRAM initialized, cache is in low/high (2-core) mode. I (1072) cpu_start: Pro cpu up. I (1076) cpu_start: Application information: I (1081) cpu_start: Project name: ovms3 I (1086) cpu_start: App version: 3.2.016-393-g07db2f8d I (1092) cpu_start: Compile time: Sep 16 2021 21:09:48 I (1099) cpu_start: ELF file SHA256: 8aa1db50ae1ea15d... I (1105) cpu_start: ESP-IDF: v3.3.4-848-g1ff5e24b1 I (1111) cpu_start: Starting app cpu, entry point is 0x40081720 I (1103) cpu_start: App cpu up. I (1989) spiram: SPI SRAM memory test OK I (1989) heap_init: Initializing. RAM available for dynamic allocation: I (1989) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM I (1996) heap_init: At 3FFBE250 len 00021DB0 (135 KiB): DRAM I (2002) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM I (2008) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM I (2015) heap_init: At 4009D5A4 len 00002A5C (10 KiB): IRAM I (2021) cpu_start: Pro cpu start user code I (2026) spiram: Adding pool of 4096K of external SPI memory to heap allocator ... Welcome to the Open Vehicle Monitoring System (OVMS) - Async Console Firmware: 3.2.016-393-g07db2f8d/factory/main Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/3 ... OVMS# module memory Free 8-bit 103580/273840, 32-bit 6440/10796, SPIRAM 3460832/4194252 ... Module Version: 3.2.016-393-g07db2f8d/factory/main (build idf v3.3.4-848-g1ff5e24b1 Sep 16 2021 21:12:48) Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/3 $ esptool.py --port /dev/tty.usbserial-0001 --baud 115200 chip_id esptool.py v2.8 Serial port /dev/tty.usbserial-0001 Connecting.... Detecting chip type... ESP32 Chip is ESP32D0WDQ5 (revision 3) Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None Crystal is 40MHzMichael should be very happy with that @ESP32D0WDQ5 (revision 3).
I’m working through the other tests now, but so far so good.
Regards, Mar.
On 14 Sep 2021, at 3:01 PM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
Progress update…
I’ve completed the basic support for plugin modem drivers and SIM7600 in the for-v3.3 branch, and it seems stable on my bench and car (although I never saw many problems before with this). I would still appreciate it if others could test and feedback any crashes they get. You can get the update OTA from api.openvehicles.com <http://api.openvehicles.com/> by setting tag ‘pre’.
We’ve also completed the testing of the hardware. The DTR low-power control option seems to be working well (but will require firmware support later). The ‘final’ list of hardware changes are as follows:
Main Board: o Silkscreen label “OVMS V3.3” (with date of production batch) o Change to improved internal antenna cables for GSM and GPS o Strengthen soldering on micro USB connector o Strengthen soldering on power supply capacitors o WROVER module to use revision 3 ESP32 o Add 0.1uF capacitor to 12v measuring voltage divider ADC input (https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/pe... <https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/peripherals/adc.html#minimizing-noise>)
Modem Board: o Silkscreen label “OVMS MDM V3.3” (with date of production batch) o Add support for SIM7600 module o Fixed DTR support o Improve/check voltage regulator and capacitor protection o Reduce brightness of blue LED by at least 50% o Airplane mode pin fix (working ok now, but safer to pull up/down properly) o Confirm PWRKEY circuit tuning
Enclosure o Product label - just one label with CE and FCC certification for global use
We are now producing a few final samples of the above to go to the certification labs for CE, FCC, and ROHS testing later this month. We hope that certification will take 6 to 8 weeks and be complete around the end of November. Once that is done, we should be able to go to full production in time for Christmas. Pricing will be confirmed early December, but likely more expensive than v3.2 due to the extra cost for SIM7600G and certification fees.
Stock of existing SIM5360 modules are as follows:
- EU kits; in stock at open energy monitor (but selling out fast and likely to be unavailable soon).
- US kits; in stock at Medlock, Fasttech, and Open Vehicles (HK).
Regards, Mark
On 30 Aug 2021, at 2:03 PM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
I now have two prototypes of the 4G modem using SIM7600G R2 chip for OVMS v3.
One is for my own work, but willing to send the other free to a volunteer developer willing to spend time working with me to develop and test this new option. Obviously looking for someone who has spent some time on the OVMS code base, with a good history of contributions to the project and a willingness to work on improving the cellular modem driver.
Any volunteers? Please eMail me directly (mark@openvehicles.com <mailto:mark@openvehicles.com>).
Regards, Mark.
<IMG_9926.png>
On 17 Aug 2021, at 1:30 PM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
For the 4G modem options we need to go through FCC, CE, and ROHS certification. Minimising/eliminating the changes to the main board simplifies this (and brings down the exorbitant costs) but if there is anything urgent / necessary, now is the time to do it.
The goal here is to maintain 100% compatibility with existing OVMS main boards, to keep this is a simple and relatively cheap upgrade of the modem board.
So far, I have come up with this minimal list:
Main board v3.3: Improve soldering of micro USB port. Bigger solder pads, and more solder to secure it better.
Modem board v1.3: Add support for SIM7600 module.
Modem board v1.3: Fix support for DTR sleep/awake support.
Is there anything else required for this update?
Regards, Mark.
OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
participants (4)
-
Alexander K -
Craig Leres -
Mark Webb-Johnson -
Michael Balzer