I have started the work on refactoring the modem driver to support virtual driver implementations (SIMCOM 5360 being just one of them). This is a major refactoring that will take some time to complete. It is likely that the following components/files will be affected: Component simcom (major changes) New component ovms_modem introduced ovms_webserver/dev/commands.htm ovms_webserver/src/web_cfg_init.cpp ovms_webserver/src/web_cfg.cpp Component powermgmt And several other components mentioning Simcom, but only very minor changes I would appreciate it if no major changes were made to those components in the next week or two, as that may make merging difficult. Once I’ve got the modem code refactored, and a compatible SIMCOM 5360 driver working, I’ll publish to the for-v3.3 branch for wider testing. I can then add the other modem drivers I have been working on. Regards, Mark. P.S. Pretty obvious that this work is to abstract out the modem type specific code, to make it easier to add support for other modem types in OVMS. This is a long-term project, and not something happening anytime soon, but I am working on it.
Good to know you're working on this. Other modem options may become a necessity sooner than we like, if more companies follow and extend on that "lite" transmitter station concept Chris reported… :-/ Regards, Michael Am 20.08.20 um 15:35 schrieb Mark Webb-Johnson:
I have started the work on refactoring the modem driver to support virtual driver implementations (SIMCOM 5360 being just one of them). This is a major refactoring that will take some time to complete. It is likely that the following components/files will be affected:
* Component simcom (major changes) * New component ovms_modem introduced * ovms_webserver/dev/commands.htm * ovms_webserver/src/web_cfg_init.cpp * ovms_webserver/src/web_cfg.cpp * Component powermgmt * And several other components mentioning Simcom, but only very minor changes
I would appreciate it if no major changes were made to those components in the next week or two, as that may make merging difficult.
Once I’ve got the modem code refactored, and a compatible SIMCOM 5360 driver working, I’ll publish to the for-v3.3 branch for wider testing. I can then add the other modem drivers I have been working on.
Regards, Mark.
P.S. Pretty obvious that this work is to abstract out the modem type specific code, to make it easier to add support for other modem types in OVMS. This is a long-term project, and not something happening anytime soon, but I am working on it.
_______________________________________________ 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 2020-08-20 06:35, Mark Webb-Johnson wrote:
I have started the work on refactoring the modem driver to support virtual driver implementations (SIMCOM 5360 being just one of them).
I'm also happy to hear this, it's something I've wanted to work on but haven't found the time; I'm sure you're a much better architect for the task. Let me know if I can help in anyway; I already have a modem board I transplanted a SIM7600A onto and a bench module to test it in. Craig
Craig, Did you ever get that SIM7600 working? It certainly requires some changes to the CMUX arrangements, as there is no CMUXSRVPORT command implemented. We’re also seeing high peak power usage on that module. 450ma to 600ma at 5V. Can’t run it off most laptop/computer USB 2 ports (the power draw brings voltage down to 4.5V or so, and brownouts occur). It seems to run ok on USB 3. We’re probably going to have to redesign the modem board power supply to get this working reliably. On the positive side, reception does seem better than the 5360 - I can even get a single in the cellular blackhole that is my home office. Regards, Mark.
On 21 Aug 2020, at 3:50 AM, Craig Leres <leres@xse.com> wrote:
On 2020-08-20 06:35, Mark Webb-Johnson wrote:
I have started the work on refactoring the modem driver to support virtual driver implementations (SIMCOM 5360 being just one of them).
I'm also happy to hear this, it's something I've wanted to work on but haven't found the time; I'm sure you're a much better architect for the task.
Let me know if I can help in anyway; I already have a modem board I transplanted a SIM7600A onto and a bench module to test it in.
Craig
On 2020-08-20 18:26, Mark Webb-Johnson wrote:
Did you ever get that SIM7600 working? It certainly requires some changes to the CMUX arrangements, as there is no CMUXSRVPORT command implemented.
Nope. I spent some time looking at the documentation and concluded it was a larger project than I wanted to engage at the time.
We’re also seeing high peak power usage on that module. 450ma to 600ma at 5V. Can’t run it off most laptop/computer USB 2 ports (the power draw brings voltage down to 4.5V or so, and brownouts occur). It seems to run ok on USB 3. We’re probably going to have to redesign the modem board power supply to get this working reliably. On the positive side, reception does seem better than the 5360 - I can even get a single in the cellular blackhole that is my home office.
Interesting. The 12V wart I'm powering my dev ovms module off of is only rated for 500 mA. But I did little more than enter some AT commands and verify that it could register on the cell network. Better reception sounds good; my motivation in going this direction is that at a minimum it would give us a better selection of cell towers to talk to. Craig
The prototype board I have is just a SIM7600 put onto our existing layout. In fact, the PCB layout we have was designed to work with either SIM5360 or SIM7600, interchangeably.That is the reason it has pads for three antenna sockets. The power issues are throwing a bit of a wrench into that plan. Perhaps when I’ve finished with the firmware refactoring of modem support, your SIM7600 will work. I’m currently planning to add firmware support for the SIM7600. Not sure which final modem module we will choose - the initial firmware support is simply proof-of-concept. I like the idea of NB-IoT, and have played with SIM7020 (no GPS/GNSS though). The SIM7000 looks interesting (LTE, NB-IoT, EDGE, and GPS/GNSS). Regards, Mark.
On 21 Aug 2020, at 10:23 AM, Craig Leres <leres@xse.com> wrote:
On 2020-08-20 18:26, Mark Webb-Johnson wrote:
Did you ever get that SIM7600 working? It certainly requires some changes to the CMUX arrangements, as there is no CMUXSRVPORT command implemented.
Nope. I spent some time looking at the documentation and concluded it was a larger project than I wanted to engage at the time.
We’re also seeing high peak power usage on that module. 450ma to 600ma at 5V. Can’t run it off most laptop/computer USB 2 ports (the power draw brings voltage down to 4.5V or so, and brownouts occur). It seems to run ok on USB 3. We’re probably going to have to redesign the modem board power supply to get this working reliably. On the positive side, reception does seem better than the 5360 - I can even get a single in the cellular blackhole that is my home office.
Interesting. The 12V wart I'm powering my dev ovms module off of is only rated for 500 mA. But I did little more than enter some AT commands and verify that it could register on the cell network.
Better reception sounds good; my motivation in going this direction is that at a minimum it would give us a better selection of cell towers to talk to.
Craig
Don’t get too excited. These are just prototypes, and a long way off from production or availability. But, fyi:
On 21 Aug 2020, at 10:41 AM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
The prototype board I have is just a SIM7600 put onto our existing layout. In fact, the PCB layout we have was designed to work with either SIM5360 or SIM7600, interchangeably.That is the reason it has pads for three antenna sockets. The power issues are throwing a bit of a wrench into that plan.
Perhaps when I’ve finished with the firmware refactoring of modem support, your SIM7600 will work. I’m currently planning to add firmware support for the SIM7600. Not sure which final modem module we will choose - the initial firmware support is simply proof-of-concept. I like the idea of NB-IoT, and have played with SIM7020 (no GPS/GNSS though). The SIM7000 looks interesting (LTE, NB-IoT, EDGE, and GPS/GNSS).
Regards, Mark.
The initial implementation of this work is in branch for-v3.3, in GitHub. That branch can be used for the upcoming 3.3 release, including potentially breaking changes. I’d appreciate any feedback. For the SIM5360, the behaviour should be unchanged from the current implementation (except some improvements to edge cases and control logic). The major user visible change is from ’simcom’ to ‘modem’ for the console commands. Regards, Mark.
On 20 Aug 2020, at 9:35 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
I have started the work on refactoring the modem driver to support virtual driver implementations (SIMCOM 5360 being just one of them). This is a major refactoring that will take some time to complete. It is likely that the following components/files will be affected:
Component simcom (major changes) New component ovms_modem introduced ovms_webserver/dev/commands.htm ovms_webserver/src/web_cfg_init.cpp ovms_webserver/src/web_cfg.cpp Component powermgmt And several other components mentioning Simcom, but only very minor changes
I would appreciate it if no major changes were made to those components in the next week or two, as that may make merging difficult.
Once I’ve got the modem code refactored, and a compatible SIMCOM 5360 driver working, I’ll publish to the for-v3.3 branch for wider testing. I can then add the other modem drivers I have been working on.
Regards, Mark.
P.S. Pretty obvious that this work is to abstract out the modem type specific code, to make it easier to add support for other modem types in OVMS. This is a long-term project, and not something happening anytime soon, but I am working on it.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Running smoothly on my bench module. Your refactorization changes also look good to me. (Side note: I'd opt for generally keeping trailing white space. I use them for graphical purposes and to denote continuing paragraphs in text files (rst), which my editor automatically does to provide consistent rewrapping.) I suggest renaming the command root "modem" to something not breaking the "mo" or "mod" shortcut for "module". I generally try to make/keep command abbreviations work at 2-3 characters. As "modem" is also a general device class (also applicable to the wifi modem), how about calling it "cellular" instead? That would also allow to add some general cellular network specific commands without breaking semantics. Regards, Michael Am 30.08.20 um 09:20 schrieb Mark Webb-Johnson:
The initial implementation of this work is in branch for-v3.3, in GitHub. That branch can be used for the upcoming 3.3 release, including potentially breaking changes.
I’d appreciate any feedback. For the SIM5360, the behaviour should be unchanged from the current implementation (except some improvements to edge cases and control logic). The major user visible change is from ’simcom’ to ‘modem’ for the console commands.
Regards, Mark.
On 20 Aug 2020, at 9:35 PM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
I have started the work on refactoring the modem driver to support virtual driver implementations (SIMCOM 5360 being just one of them). This is a major refactoring that will take some time to complete. It is likely that the following components/files will be affected:
* Component simcom (major changes) * New component ovms_modem introduced * ovms_webserver/dev/commands.htm * ovms_webserver/src/web_cfg_init.cpp * ovms_webserver/src/web_cfg.cpp * Component powermgmt * And several other components mentioning Simcom, but only very minor changes
I would appreciate it if no major changes were made to those components in the next week or two, as that may make merging difficult.
Once I’ve got the modem code refactored, and a compatible SIMCOM 5360 driver working, I’ll publish to the for-v3.3 branch for wider testing. I can then add the other modem drivers I have been working on.
Regards, Mark.
P.S. Pretty obvious that this work is to abstract out the modem type specific code, to make it easier to add support for other modem types in OVMS. This is a long-term project, and not something happening anytime soon, but I am working on it.
_______________________________________________ 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
“Cellular” sounds good. I will make the change. “mod<tab>” has been aggravating me. P.S. Still working on it, but hopefully SIM5360 is working well.
On 30 Aug 2020, at 5:39 PM, Michael Balzer <dexter@expeedo.de> wrote:
Running smoothly on my bench module.
Your refactorization changes also look good to me. (Side note: I'd opt for generally keeping trailing white space. I use them for graphical purposes and to denote continuing paragraphs in text files (rst), which my editor automatically does to provide consistent rewrapping.)
I suggest renaming the command root "modem" to something not breaking the "mo" or "mod" shortcut for "module". I generally try to make/keep command abbreviations work at 2-3 characters.
As "modem" is also a general device class (also applicable to the wifi modem), how about calling it "cellular" instead?
That would also allow to add some general cellular network specific commands without breaking semantics.
Regards, Michael
Am 30.08.20 um 09:20 schrieb Mark Webb-Johnson:
The initial implementation of this work is in branch for-v3.3, in GitHub. That branch can be used for the upcoming 3.3 release, including potentially breaking changes.
I’d appreciate any feedback. For the SIM5360, the behaviour should be unchanged from the current implementation (except some improvements to edge cases and control logic). The major user visible change is from ’simcom’ to ‘modem’ for the console commands.
Regards, Mark.
On 20 Aug 2020, at 9:35 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
I have started the work on refactoring the modem driver to support virtual driver implementations (SIMCOM 5360 being just one of them). This is a major refactoring that will take some time to complete. It is likely that the following components/files will be affected:
Component simcom (major changes) New component ovms_modem introduced ovms_webserver/dev/commands.htm ovms_webserver/src/web_cfg_init.cpp ovms_webserver/src/web_cfg.cpp Component powermgmt And several other components mentioning Simcom, but only very minor changes
I would appreciate it if no major changes were made to those components in the next week or two, as that may make merging difficult.
Once I’ve got the modem code refactored, and a compatible SIMCOM 5360 driver working, I’ll publish to the for-v3.3 branch for wider testing. I can then add the other modem drivers I have been working on.
Regards, Mark.
P.S. Pretty obvious that this work is to abstract out the modem type specific code, to make it easier to add support for other modem types in OVMS. This is a long-term project, and not something happening anytime soon, but I am working on it.
_______________________________________________ OvmsDev mailing list 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 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
On 2020-08-30 00:20, Mark Webb-Johnson wrote:
The initial implementation of this work is in branch for-v3.3, in GitHub. That branch can be used for the upcoming 3.3 release, including potentially breaking changes.
I’d appreciate any feedback. For the SIM5360, the behaviour should be unchanged from the current implementation (except some improvements to edge cases and control logic). The major user visible change is from ’simcom’ to ‘modem’ for the console commands.
I built and flashed this version on my dev module and was able to register on the cell network and get a gps fix (sim5360). I swapped in my sim7600 modem board, switched the 500 mA power adapter for a 1.5A version and booted. Very shortly after booting the /status page showed "Unrecognised command" for the modem. But "cellular" showed this: OVMS# cell MODEM Status Model: SIM7600 Network Registration: Searching Provider: Signal: 0 dBm State: NetWait Mux: Status up PPP: Not running GPS: Connected on channel: #1 I was using the serial console and notice that "cell" command worked without enable but "location status" (still) required enable mode. I don't have a lot of confidence in my cell antenna setup, the best I can say about it is it worked with the sim5360 and it's the same as what I've been using my my Corvette (the gm oem onstar windshield antenna with separate cell and gps connections). I dug out a pair of fasttech antennas and used the web page to cycle power on the modem. After this point the module was unable to identify the module. I tried rebooting and that didn't help. I cycled power and it was able to id the simcom again but still no network registration or gps. The next time I did a warm reboot the MODEM Status Model was again stuck on auto. I don't have any time left this weekend for serious debugging but I'm game if there are simple things you'd like me to try. Craig
Craig, I haven’t completed the SIM7600 and SIM7000 drivers yet. Apart from a few minor command differences, they both seem to expose a bug in our MUX driver which sometimes causes a crash (particularly in areas of poor cellular connectivity). I’l guessing just some unknown / unhandled frame type. Model recognition should work now. But the power cycle for these modems is tricky. If you want to have a look at the SIM7600 driver, that is fine by me. I won’t have time to look at it for a couple of weeks I think (trying to bring across all my old work on the plugin system first). I am really just trying to get the low level refactoring done at the moment (which is pretty much done now). The code is in simcom_7600.cpp, and is very small. I remember the big init command has some unrecognised stuff in it, but haven’t had time to remove/fix them yet: 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 The modem can now be put into ‘power modem devel’ mode, where you can simply ‘cellular tx AT…’ commands to it. Send each of the above, one by one, and you’ll find the incorrect ones. I seem to remember there were two. Regards, Mark.
On 31 Aug 2020, at 11:51 AM, Craig Leres <leres@xse.com> wrote:
On 2020-08-30 00:20, Mark Webb-Johnson wrote:
The initial implementation of this work is in branch for-v3.3, in GitHub. That branch can be used for the upcoming 3.3 release, including potentially breaking changes. I’d appreciate any feedback. For the SIM5360, the behaviour should be unchanged from the current implementation (except some improvements to edge cases and control logic). The major user visible change is from ’simcom’ to ‘modem’ for the console commands.
I built and flashed this version on my dev module and was able to register on the cell network and get a gps fix (sim5360).
I swapped in my sim7600 modem board, switched the 500 mA power adapter for a 1.5A version and booted. Very shortly after booting the /status page showed "Unrecognised command" for the modem. But "cellular" showed this:
OVMS# cell MODEM Status Model: SIM7600 Network Registration: Searching Provider: Signal: 0 dBm State: NetWait Mux: Status up PPP: Not running GPS: Connected on channel: #1
I was using the serial console and notice that "cell" command worked without enable but "location status" (still) required enable mode.
I don't have a lot of confidence in my cell antenna setup, the best I can say about it is it worked with the sim5360 and it's the same as what I've been using my my Corvette (the gm oem onstar windshield antenna with separate cell and gps connections). I dug out a pair of fasttech antennas and used the web page to cycle power on the modem. After this point the module was unable to identify the module. I tried rebooting and that didn't help. I cycled power and it was able to id the simcom again but still no network registration or gps. The next time I did a warm reboot the MODEM Status Model was again stuck on auto.
I don't have any time left this weekend for serious debugging but I'm game if there are simple things you'd like me to try.
Craig
Given that "simcom" defaults to "simcom status" (and you must use "simcom ?" to see all sub-commands) would it be reasonable for "location" to default to "location status"? Craig
On Mon, 31 Aug 2020, Craig Leres wrote:
Given that "simcom" defaults to "simcom status" (and you must use "simcom ?" to see all sub-commands) would it be reasonable for "location" to default to "location status"?
Seems reasonable to me. You can also use "simcom <TAB>" to see all the subcommands in a way that I think is more convenient because you can then just continue typing the desired subcommand. -- Steve
Yes, this should be the standard (for any command that implements ’status’). I implemented this in the for-v3.3 branch. The following are affected: canopen egpio location ota server v2 server v3 tls tpms re sd vehicle bms log notify event I notice that there are a few subsystems that don’t have a ’status’ command at all. Perhaps that should be standardised as well? Regards, Mark.
On 1 Sep 2020, at 2:03 AM, Craig Leres <leres@xse.com> wrote:
Given that "simcom" defaults to "simcom status" (and you must use "simcom ?" to see all sub-commands) would it be reasonable for "location" to default to "location status"?
Craig _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
I just tried updating my dev module from 3.2.014-103-gcf346399-dirty to 3.2.015-151-g3377eed0-dirty and I find the wifi stops working after a few minutes. Right after a boot I connect to the webserver but once I submit a page I start getting timeouts. I can also connect to the ssh port but ssh -v doesn't show any negotiation. I reverted to the older version and it works again. My only local changes are to ifdef out some simcom_7600.cpp init code so I can work on trying figure out the correct init sequence. Craig
Craig, no wifi issues here running 3.2.015-151-g3377eed0. Did you try a clean build? Regards, Michael Am 10.10.20 um 03:06 schrieb Craig Leres:
I just tried updating my dev module from 3.2.014-103-gcf346399-dirty to 3.2.015-151-g3377eed0-dirty and I find the wifi stops working after a few minutes. Right after a boot I connect to the webserver but once I submit a page I start getting timeouts. I can also connect to the ssh port but ssh -v doesn't show any negotiation. I reverted to the older version and it works again.
My only local changes are to ifdef out some simcom_7600.cpp init code so I can work on trying figure out the correct init sequence.
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
Following on from this, I’ve now brought across my previously uncommitted changes for ovms_script / ovms_command to the for-3.3 branch. This is a big set, affecting a bunch of modules. The issues here were: Duktape object and function resolution was in ovms_script, which loads quite late. After events and config, for example - so the extensions for those had to be put in ovms_script rather than their own files - ugly. The ovms_script was dependent on ovms_command, which was dependent on ovms_script. Horrible. The solution I implemented is to move duktape to ovms_duktape, and load that very early for duktape object and function registration. That avoids all the inter-dependency issues and allows anything to register duktape extensions. The ovms_duktape / ovms_script code was also massive (> 3,000 lines), so I moved the non-code stuff out to their own files. Probably more can be done here, but at least now it is manageable at around 1,300 lines. With that done, I should be able to finally get the javascript command extensions implemented (the main justification for this work). This will allow javascript modules to register ovms command handlers and extend the command line. Regards, Mark.
On 30 Aug 2020, at 3:20 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
The initial implementation of this work is in branch for-v3.3, in GitHub. That branch can be used for the upcoming 3.3 release, including potentially breaking changes.
I’d appreciate any feedback. For the SIM5360, the behaviour should be unchanged from the current implementation (except some improvements to edge cases and control logic). The major user visible change is from ’simcom’ to ‘modem’ for the console commands.
Regards, Mark.
On 20 Aug 2020, at 9:35 PM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
I have started the work on refactoring the modem driver to support virtual driver implementations (SIMCOM 5360 being just one of them). This is a major refactoring that will take some time to complete. It is likely that the following components/files will be affected:
Component simcom (major changes) New component ovms_modem introduced ovms_webserver/dev/commands.htm ovms_webserver/src/web_cfg_init.cpp ovms_webserver/src/web_cfg.cpp Component powermgmt And several other components mentioning Simcom, but only very minor changes
I would appreciate it if no major changes were made to those components in the next week or two, as that may make merging difficult.
Once I’ve got the modem code refactored, and a compatible SIMCOM 5360 driver working, I’ll publish to the for-v3.3 branch for wider testing. I can then add the other modem drivers I have been working on.
Regards, Mark.
P.S. Pretty obvious that this work is to abstract out the modem type specific code, to make it easier to add support for other modem types in OVMS. This is a long-term project, and not something happening anytime soon, but I am working on it.
_______________________________________________ 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
participants (4)
-
Craig Leres -
Mark Webb-Johnson -
Michael Balzer -
Stephen Casner